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© Integrated trading. 


© integrated trading provides both automatic 
matching trades for trading instruments between po- 
tential counterparties arid video conversational nego- 
tiated trades for trading instruments between poten- 
tial counterparties using integrated keystations {202. 
204. 206. 208) winch are selectively connectabie 
together. Each of the keystations (202, 204, 208. 
208} includes 3 data input device, such as a key- 
board (240} and a mouse (242), and an integrated 
screen display (238), with the keyboard (240) and 
the display (238} being shared ior both the automatic 
matching trades effectuated by the keystation (202. 
204 ( 208. 208} through a matching network (220} and 
the video conversational negotiated trades keystation 
(202. 204, 206, 208} through a separate conversation 
network {21&}. An integrated terminal controller (214, 
218} is provided as a common interface between the 
keystations (202. 204. 206, 208) and the separate 
networks (2iS. 220}. Transaction data is provided 
between given keystations (202, 204. 206, 208} in 


the system (200} relating to both automatic matching 
transactions and video conversational negotiated 
trading transactions through the common integrated 
terminal controller (214, 216) which interfaces with 
the separate communication paths associated with 
the automatic matching trades (220} and the video 
conversations! negotiated trades (218) effectuated by 
the keystation (202, 204, 206, 20S}. The integrated . 
terminal con;rotlef(2i4. 218) comprises a conversa- 
tion server (252), a concentrator computer (254), the 
terminal computers (250} associated with the various 
keystations (202, 204. 206, 208} it serves, and 3 
tccal area network (256) tieing them together, initiai 
access to both types of trades can be obtained at 
log on. A' common ticket generation scheme for both 
types. oS trades is used so that trading tickets may 
be collected and communicated to a remote back 
office data base through the integrated terminal con- 
troller (214, 218). via the conversation server (252). 
irrespective of the type of trade completed. 
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INTEGRATED TRADING 


The present invention relates to effectuating 
trades of trading instruments both through auto- 
matic matching, in which buyers and sellers who 
are willing to trade with one another based on 
specified criteria may automatically trade when 
matching events occur satisfying these criteria, and 
through video converstaional negotiated trades, in 
which buyers and sellers who are willing to trade 
with one another may do so through exchanging 
video conversational textual messages, and are 
particularly to the methodology of integrating these 
different types of trades in a system which enables 
individual keystations to accomplish both types of 
trades. 

Information retrieval systems for financial in- 
formation, such as stock market type of information 
and money market information, normally employ a 
transfer of data in a high performance, real time 
information retrieval network in which update rates, 
retrieval rates and subscriber and/or user popula- 
tion are generally very high. An example of such a 
system is REUTERS DEALING SERVICE, which is 
used in the foreign exchange market, or GLOBEX, 
which is used by the Chicago Mercantile Exchange 
for electronic trading in the commodities market. 
Such systems, while providing rapid communica- 
tion capability between subscribers, have been pre- 
viously dedicated to one type of trading capability, 
albeit video conversation capability to effectuate 
negotiated trades through textual messages ex- 
changed between potential counterparties, such as 
in DEALING, or automatic matching capability to 
automatically effectuate trades between anony- 
mous potential counterparties meeting certain user 
specified criteria, such as in GLOBEX. Each of 
these types of systems have their place in the 
market and serve particular needs where appro- 
priate. However, because of world of trading of 
financial instruments and the requisite needs asso- 
ciated therewith are dynamic and rapidly change 
with changes in the surrounding circumstances, at 
one moment it may be desirable to trade anony- 
mously in an automatic matching environment 
while at the very next moment it may be desirable 
to openly trade in a video conversational negotiat- 
ing environment, or to do both, for the same or 
different trading instruments. Thus, although there 
have been successful trading systems doing one of 
these types of trades, there are no known prior art 
systems which effectively integrate both of these 
types of trades in a single system so as to permit a 
trader, using a single keyboard and display screen, 
to selectively switch between the two types of 
trading systems dependent on his own desires and 
needs at any given time in the trading environment. 


This is so despite the known technique in the prior 
art of tying common keyboard, such as described 
in US-A-4,404,551, in which a common keyboard is 
used to both communicate with multiple computer 
5 systems and multiplex or dynamically route or se- 
lect video displays on one or more VDUs from a 
plurality of simultaneously provided composite vid- 
eo signal inputs from these multiple computer sys- 
tems in response to unique keyboard generated 
w character codes. 

In addition, despite known prior art systems 
which have attempted to integrate voice and data, 
such as disclosed in US-A-4,612,416; 4,598,367; 
4,653,045; 4,475,189; 3,344,401; and 4,635,251, 
is none of these prior art systems, has integrated 
conversational trading, to enable negotiated trades, 
with automatic matching trades; to enable anony- 
mously matched trades, in a shared environment. 
For example, the system disclosed in US-A-4, 
20 598,367 is a financial quotation system employing 
a keypad input and a synthesized speech output, 
but does not integrate different types of trading 
transactions in a shared environment. Similarly, 
US-A-4, 509,167; 4,612,416; and 4,635,251, which 
25 are not directed to financial . information per se, 
merely disclose systems which integrate voice"mail 
in a telephone communication system. US-A- 
4,653,045 and 4,475,189 also disclose telephone 
systems which integrate voice and data, with these 
30 systems being used in telephone conferencing. 
US-A-3.344,401, discloses another type of tele- 
phone system in which voice is integrated with 
teletype for communicating with a remote data 
processor in an inquiry system; however, the dis- 
35 closed system is not utilized in a dynamic trading 
environment, such as one involving matching trans- 
actions and/or video conversational negotiated 
trades. 

Moreover, automatic matching trading systems 
40 are well known, such as described in US-A- 
3,573,747; 3,581,072; 4,412,287; 4,677,552; and 
4,674,044, as well as in EP-A-90305753; 0,399,850; 
90305763; and GB-A-2,227,625; 2,226,217; and 
2,224,141. However, although these prior art auto- 
45 matic matching systems are capable of automati- 
cally matching bids and offers, and may employ a 
central or host computer to accomplish this, such 
as disclosed in US-A-4,677,552; 4,674,044; and 
3,573,747; by way of example, they are incapable 
so of enabling video conversational negotiated trades 
to also occur, thereby requiring a totally different 
system to be employed if the trader desires to then 
execute such a trade. This can provide significant 
trading disadvantages to the trader. 

In addition, although the REUTERS DEALING 
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SERVICE, enables multiple conversations to be 
carried out by a given subscriber in reai time and 
m association with data base retried of supple- 
mentary data, such as described tn US-A-4,53S.l34 
and 4.525,779, by way of example, as well as in 
the Aforementioned EP and G8 specifications relat- 
ing to video conversational trading systems, none 
of these systems integrates an automatic matching 
trading system with one capable of providing video 
conversational negotiated trades. 

Apart from the above, there are no known 
trading systems of this type in which a keep alive 
signal is periodically provided to the system in 
order to notify the system that a given subscriber 
keystation is operating properly so that ail out- 
standing active bids and offers associated with the 
keystation can be automatically deleted from the 
trading system if the keystation fails or is unable to 
provide the periodic keep afive signal to the sys- 
tem. This enables a trader who becomes mechani- 
cally locked out from active trading by keystation 
failure to be automatically removed from the trad- 
ing base so as to ensure that completed trades are 
accomplished oniy between active traders who are 
able to participate in the trading transactions which 
are occurring, whether they are anonymous trades 
or negotiated trades 

Another feature lacking in the known prior ad 
relates to the provision of a high speed, reliable 
system for providing a common ticket generation 
scheme for providing trading ticket information to a 
back office computer without continual polling, ir- 
respective of the type of deal or trade which has 
occurred. Although reliable ticket generation 
schemes ate known, such as described in the 
above aforementioned EP and OB specifications 
relating thereto, and although methods and sys- 
tems for dynamically controlling the content of a 
local receiver data base from a transmitted data 
base in an information retrieval communication net- 
work for collecting financial information are also 
known, such as described in uS-A-4.745,559, no 
pnor art systems ate known which provide com- 
mon ticket generation for automatic matching 
trades and for video conventional negotiated 
trades, nor are any such pnor ad systems known in 
which both iypes of completed trades may be 
stored together lor retrieval. 

Thus, the'e are no known pnor art systems or 
methods which can readily combine the advan- 
tages, speed and reliability of both automatic 
matching and negotiated video conversational 
trades to a single system so as to provide the 
individual subscribers or keystations with maximum 
flexibility and optimal efficiency to effectuate the 
type o: trade demanded by the time and circum- 
stances available. These disadvantages of the prior 
art are overcome by the method of the present 


The present invention is set out in its various 
aspects m the independent claims of the present 

application. 

s An example of the invention will now be de- 

scribed with reference to the accompanying draw- 
ings in which: 

Fig f Is an overall system functional block dia- 
gram of a system capable of carrying out an 

;o integrated trading method: 

Fig 2 is a functional block diagram of a typical 
client site in She system of Fig 1, illustrating a 
typical preferred integrated terminal controller; 
Fig 3 is a functional block diagram similar to 

;s Fig. 2, illustrating the portion of the presently 
preferred integrated terminal controller relating 
to the carrying out of video conversational nego- 
tiated trades; 

Fig 4 is a diagramatic illustration of a typical 
to communication network for carrying out video 

conversational negotiated trades; 

Fig 5 is a diagramatic illustration of a typical 

terminal computer associated with a typical 

keystation in the system of Fig. 1 ; 
?5 Fig 6 is a diagramatic illustration, similar to Fig. 

5. of a typical conversation server portion of the 

presently preferred integrated terminal controller 

of Fig. 2; 

Fig 7 is a functional block diagram, similar to 
aa Fig, 4, illustrating the network associated with 

carrying out automatic matching trades in the 
system of Fig. f; 

Fig a is a functional block diagram of the net- 
work of Fig. 7 illustrating the flow of information 

as m connection with the entry of a bid--and the 
entry of an offer in connection with effectuating 
automatic matching trades between potential 
counterparties in the system of Fig. 1 ; 
Fig 9 is a functional block diagram similar to 

-id Fig, 8, of the flow of information in the network 

of Fig 7 in connection with a hit bid or trade in 
connection with the carrying out of automatic 
matching trades between potential counterpar- 
ties in the system of Fig i; 

45 Fig 10 is a diagramatic illustration of a typical 
integrated video screen display for a typical 
integrated keystation m the system of Fig. i 
when the small font option has been selected; 
Fig 11 is a diagramatic illustration, similar to Fig 

*cj 10, of a typical integrated video display screen 

layout when matching has been selected by the 
integrated keystation in Fig.t; 
Fig 12 is a diagramatic illustration, similar to Fig, 
10, of the video screen layout of Fig. 1! when 

as the video conversational trade option has been 
selected with the display of Fig 12 toggling with 
the display of Fig. 1 1 ; 

Fig 13 is a diagramatic illustration similar to rig 
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10 of a typical integrated video screen display 
for a typical integrated keystation in the system 
of Fig. 1 when the large font option has been 
selected and the matching trade option has 
been selected; 5 
Fig 1 4 is a diagramatic illustration similar to Fig. 
13, of a large font option for a typical integrated 
video screen display of a typical integrated 
keystation in the system of Fig. 1 when the 
video conversational trade option has been se- to 
lected, with the screen of Fig. 14 toggling with 
the screen of Fig. 13; 

Fig 15 is a diagramatic illustration of a typical 
integrated keyboard associated with a typical 
integrated keystation in the system of Fig. 1; is 
Fig 16 is an illustration of a typical matching 
ticket produced as a result of a matching trade 
in the system of Fig. 1; 

Fig 17 is a diagramatic illustration, similar to Fig. 
16, of a typical conversation ticket produced in 20 
response to the completion of video conversa- 
tional negotiated trade in the system of Fig. 1 : 
Fig 18 is a diagramatic state diagram of the 
sequence of operations associated with log on 
and log off a typical integrated keystation in the 25 
system of Fig. 1 ; 

Figs 19-20 comprise a logic flow diagram of the 
log on/log off sequence of operations illustrated 
in the state diagram of Fig. 18; 

Figs 21-24 are diagramatic illustrations of typical 30 
integrated video screen displays for a typical 
integrated keystation in the system of Fig. 1, 
illustrating the integrated trading capabilities of 
the system of Fig. 1, with Fig. 21 illustrating a 
typical integrated video display in which both 35 
information relating to automatic matching 
trades and information relating to video con- 
versational negotiated trades is present on the 
screen, but no trade has occurred with that 
keystation, with Fig 22 illustrating the screen of 40 
Fig. 21 with information about to be transmitted 
in connection with completion of a matching 
transaction, with Fig. 23 illustrating the automatic 
matching trade represented in Fig. 21 as having 
been executed and match notification having 45 
been received by the keystation, and with Fig 24 
illustrating the integrated display screen of Fig. 
21 when a video conversation negotiated trade 
has been completed; 

Fig 25 is a logic flow diagram of the operation of 50 
a typical integrated keystation in the system of 
Fig. 1 in response to receipt of a match notifica- 
tion signal; 

Fig 26 is a logic flow diagram, similar to Fig. 25, 
of the operation of a typical integrated keysta- 55 
tion in the system of Fig. 1 in response to 
receipt of a match ticket or conversation ticket; 
Figs 27-29 are logic flow diagrams, similar to 


Fig. 25, illustrating the operation of a typical 
integrated keystation in the system of Fig. 1 with 
respect to the keep alive feature, with Fig. 27 
illustrating the operation of the integrated key- 
board, and Figs. 28 and 29 illustrating the op- 
eration of the terminal computer portion of the 
integrated keystation; 

Fig 30 is a functional block diagram illustrating 
the flow of information in connection with a 
typical matching transaction; 
Fig 31 is a diagramatic illustration of a portion of 
the trading ticket output process utilizable in the 
system of Fig. 1 concerned with the ticket out- 
put protocol; 

Fig 32 is a logic flow diagram of a ticket output 
process; 

Fig 33 is a logic flow diagram of the operation of 
the integrated terminal controller when a new 
trading ticket has been generated in accordance 
with the trading ticket output process of Fig. 32; 
Fig 34 is a logic flow diagram of the operation of 
the database server portion of the integrated 
terminal controller in the system of Fig. 1 with 
respect to requests for tickets received by the 
database server from a back office computer; 
Fig 35 is a logic flow diagram of the data 
display application for initiating a fast conversa- 
tional contact message using the screen pointer 
in a typical integrated keystation in the system 
of Fig. 1; and 

Fig 36 is a logic flow diagram of the conversa- 
tion application processing of a fast conversa- 
tional contact message initiated in accordance 
with Fig. 35 for expanding the contact message 
and establishing conversational contact in the 
system of Fig. 1 . 
An integrated trading system 200, as will be 
described in greater detail hereinafter, is capable of 
effecting trades of trading instruments both through 
automatic matching, in which buyers and sellers 
who are willing to trade with one another based on 
specified criteria may automatically trade when 
matching events occur satisfying these criteria, and 
through video conversational negotiated trades, in 
which buyers and sellers who are willing to trade 
with one antoher may do so through exchanging 
video conversational textual messages. Individual 
integrated keystations, with four such integrated 
keystations 202, 204, 206 and 208 being shown by 
way of example in Fig. 1, are able to accomplish 
both types of trades. In addition, as will be de- 
scribed in greater detail hereinafter individual 
keystations which are only capable of performing 
one of these types of trades can trade with another 
keystation of that type or with an integrated keysta- 
tion which is capable of performing both types of 
trades. In this regard, as shown and preferred in 
Figs. 1 and 2, an integrated terminal controller with 
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two such client sites 210, 212 being illustrated by 
way of example, in Fig. 1. One such integrated 
terminal controller 214, 216 is illustrated at each 
client site 210, 212, respectively, by way of exam- 
ple, in Fig. 1 . 

As shown and preferred in Figs. 1 and 2, a 
typical integrated terminal controller 214, may ac- 
commodate a plurality of integrated keystations 
202, 204, by way of example, and is the system 
interface for these keystations 202, 204 with the 
other keystations 206, 208 in the system 200 in 
order to enable the different types of trades to be 
effected with these integrated keystations 202, 204, 
206, 208. As shown by way of example in Fig. 1, 
each type of trade, namely video converstational 
negotiated trades and automatic matching trades, 
has its own associated communication network 
218, 220 respectively, since the population of in- 
dividual subscribers involved in automatic matching 
trades. In this regard, there is a host computer 222 
associated with the routing of conversational trade 
and there is a separate matching host computer 
224 which is actually responsible for the matching 
trades which occur through the matching commu- 
nication network 220, such as described in greater 
detail in the above European publications. Suffice it 
to say that the present control and operation of 
automatic matching trades is preferably the same 
as described in these EP and GB specifications, 
with the exception of the involvement of the in- 
tegrated terminal controller 214, 216, with reference 
to a typical terminal controller 214 to be described 
in greater detail hereinafter, and . the use of the 
integrated keystation 202, 204, 206, 208 with the 
operation of a typical integrated keystation 202 to 
be described in greater detail hereinafter. 

A common ticket generation scheme and ticket 
output feed to the back office computer is used for 
both the video conversational negotiated trades 
performed by the system 200 and the automatic 
matching trades performed by the system 200. 
Similarly, with respect to the video conversational 
negotiated trades performed by the system 200, 
these trades are preferably performed in the same 
manner as described in GB-A-2,226,217 and GB-A- 
2,227,625, with the exception, once again of the 
involvement of the integrated terminal controller 
214, 216 and the integrated keystations 202, 204, 
206, 208, which enables both this type of trade and 
the automatic matching trades to be integrated in 
the same system 200 and provided on a common 
video display 238, and which provides a common 
ticket generation scheme for both types of trades. 
With respect to the common ticket generation 
scheme, except for the differences to be described 
hereinafter, the ticket generation in the system 200, 
which also describes the provision of the ticket 
output fee to the back office computer. 


As shown in Fig. 1, each of the integrated 
terminal controllers 214, 216, has an associated 
ticket printer 226, 228 respectively, and an asso- 
ciated conversation printer 230, 232, respectively, 

s as well as a ticket output feed 234, 236, respec- 
tively, to its associated back office computer. With 
respect to the individual integrated keystations 202, 
204, 206, 208 to be described in greater detail 
hereinafter, a typical integrated keystation 202 pref- 

70 erably has an integrated screen display 238, to be 
described in greater detail hereinafter and illus- 
trated by way of example, in Figs. 10-14 and Figs. 
21-24, an integrated keyboard 240, such as the 
typical keyboard illustrated in Fig. 15, and a con- 

75 versational mouse 242 which may preferably be 
used to accomplish fast conversational contact, by 
way of example, such as in the manner described 
in GB-A-2,227,625, and illustrated, by way of exam- 
ple in Figs. 35-36 which correspond to Figs. 11-12 

20 of GB-A-2,227,625. 

As shown in Fig. 2, the integrated terminal 
controller 214 comprises a terminal computer 250 
associated with each keystation. The terminal com- 
puter 250 is preferably a conventional computer 

25 configuration, such as an 80386 Intel 302 computer 
for each integrated keystation 202, 204, 206. 208. 
In addition, the integrated terminal controller 214 
also preferably includes a conversation server com- 
puter 252, such as one comprising another 80386 

30 Intel 302 computer, and which is shown in greater 
detail in Fig. 3, and a concentrator computer 254, 
such as a MICRO VAX 2000 computer, for commu- 
nicating with the matching host computer 224 
through the matching communication network 220. 

35 The conversation server 252, the concentrator 
computer 254, and the terminal computers 250 
associated with the various integrated keystations 
202, 204, for example, are all preferably tied to- 
gether through a conventional local area network 

40 256, such as an Ethernet network, with the con- 
centrator computer 254 preferably communicating 
with the conversation server 252 via the keystation 
terminal computer 250 connected to the local area 
network 256. As shown and preferred in Figs. 2 

45 and 3, and as will be described in greater detail 
hereinafter, the conversation server 252, which is 
shown in greater detail in Fig. 6. not only handles 
video conversational trading, but preferably ties 
together, in the integrated system 200, the printing 

so and ticket generation for both automatic matching 
trades and video conversational negotiated trades 
performed by a given integrated keystation 202, 
204 associated with that integrated terminal control 
ler 214, and is the interface with the associated 

55 back office computer for the ticket output feed for 
trades performed at that client site 210, irrespective 
of the type of trade performed. 

As shown and preferred in Fig. 3, although the 
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conversation server 252 is represented by only one 
block in Fig 2, in teality i; may be comprised of a 
line server 264 which enables, for example, the 
provision of context sensitive prompts during con- 
versational trading, such as described in greater 
detail in G8-A-2,226,217. Thus, the conversation 
server 252, such as illustrated in Pig. 0, performs 
several different functions in the system 200 of the 
present invention. The conversation server 252 
handles communications with the conversation 
comunnicatton network 218. such as DEALING, 
maintains a database vrnih respect to DEALING 
conversations, trade logs and tickets, drives various 
printers 228. 230, analyzes conversations in 
progress, and generates a serial ticket output feed, 
via path 234. for provision of this feed to the back 
office computer. By way of example, in accom- 
plishing this task, the conversation server computer 
252. may. by way of example comprise at least 4 
megabytes of memory, a 40 megabyte hard disk, a 
high density floppy, an Ethernet card with 512 
kilobytes of memory, conventional RS232 Serial 
Connections, an STB VGA extra memory video 
card generating a TIL output, and the appropriate 
software to communicate with the conversation 
communication network 218, These components 
are illustrated, by way of example, in Pig. 6. With 
respect to the associated printers 226, 230. the 
conversation printer 230 preferably prints conversa- 
tions as they are completed, whereas the ticket 
printer £26 preferably pnnts a single ticket for each 
matching trade as well as each confirmed video 
conversational negotiated trade. Of course, other 
printers may be associated with the integrated ter- 
minal controller 214, such as an audit trad printer 
280 or other standby printers if desired. With re- 
spect fo the typical terminal computer 250, such a 
terminal computer 250 is illustrated in further dot ait, 
by way of example, in Fig. 5. Thus, by way of 
example, the terminal computer 250 such as an 
■met 302 PC, which may also be employed for the 
conversation server 252 as illustrated in Fig. S, 
preferably includes an RS232 input for a serial 
keyboard 240 and a serial mouse 242, a 512K 
Ethernet card, a conventional device for driving an 
analog screen 233. a 40 megabyte hard disk, and 
at least 3 megabytes of memory. H should be 
noted, that the -terminal computer 250 illustrated m 
Fig. 5 is merely illustrated by way of example, and 
other conventional computers capable of use with 
the system 200 may also be employed instead of 
or in conjunction with terminal computer 250. 

it should be noted with reference to Fig. 2 thai, 
although only one conversation server 252 is illus- 
trated as being connected to the local area network 
256, ii desired, a plurality of conversation servers 
252 can be connected to the same section of the 
Ethernet Network 256, with there still being a single 


concentrator computer 254 for supporting matching 
connected fo the local area network 256. By way of 
example, each conversation server 252 may sup- 
port up to 1 2 keystations for conversational trading 
s and matching trades, with the concentrator com- 
puter 254, by way ol example, being a Micro VAX 
2000 computer having a Ethernet interface, a hard 
disk, a pair of Asynchronous Serial lines to the 
matching communication network 220, and appro- 
re prists software, such as referred to in the afore- 
mentioned EP and G8 specifications, it should be 
noted that, by way of example, in the instance of 
12 keystations being associated with a given in- 
tegrated terminal controller 2 14, the 12 keystations 
?5 need not all be supported by the same conversa- 
tion server 252, as mentioned above, even though 
the 12 keystations couid be supported by a single 
concentrator computer 254. 

As will be described with reference to Figs. 10 
so - f4, different screen layouts for the integrated 
screen display 236 may be provided, with Fig. 10 
illustrating the small font option preferably for use 
with large video screens such as 12 - 14 inch 
screens, and with Figs. 13 and 14 illustrating the 
large font option preferably for use with smaller 
video screens such as 1Q inch screens or when the 
user requires a simple display. Figs. IS and 12 
illustrate the screen layout oi the integrated screen 
display 238 in which, by way of example, a 14 row 
so general display area is provided by overlaying the 
matching trade and conversational trade windows 
in the display, with Fig. 1 1 illustrating the integrated 
screen display 233 when matching has been se- 
lected by the user at the keystation, and with Fig. 
ss 12 illustrating the integrated screen display 238 
when conversational trading has been selected by 
me user at the keystation, with the integrated 
screen display 238 toggling between the layout 
illustrated in Fig. f f and the layout illustrated <n 
40 Fig. 12 depending on she option selected. Prefer- 
ably, any of the screen layouts illustrated in Figs. 
10 -14 may be selected by the user at the keysta- 
tion for providing the desired integrated screen 
display 238. In this regard, it should be noted that 
•;s the keystation may be run under commercially 
available windowing software, such as Microsoft 
Windows 386 version 2. J, DOS 3-3 and the Win- 
dows version of the Workstation Environment 
(WSE). tn the screen layout for the integrated 
so screen display 238 illustrated in Fig. 10, the current 
entries in the market for potential automatic match- 
' ing trades are preferably contained in area 260 with 
the results of the particular keystation' S recent 
automatic matching trade activity preferably being 
ss ■ contained in the area immediately below and given 
reference number 262. As illustrated in Fig. 10. in 
the area immediately below that is the window 
which contains conversational trading activity and 
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may. by way of example, contain up to four such 
separate trading conversations of the type referred 
to in the aforementioned patents and EP and GB 
specifications relating to conversational trading. 
This area has been given reference numeral 264. 
Immediately to the right of that area in the screen 
layout illustrated in Fig. 10 is an area designated 
for displaying incoming calls as well as conversa- 
tion analysis summaries, such as referred to in the 
aforementioned patents and EP and GB specifica- 
tions, with conversation analysis summary being 
described and referred to in the aforementioned 
GB-A-2,226.217, and with this area being given 
reference numeral 266. In connection with the dis- 
play of multiple trading conversations in area 264, 
when conversational trading is selected by the in- 
tegrated keystation given the screen layout of Fig. 
10, preferably there is provision for a heading and 
at least 7 lines of the current conversation, and at 
least a heading and 1 line of text for up to three 
more trading conversations. Immediately below 
area 264 is a display area for Dealing or conversa- 
tional trading command responses, with that area 
being designated with reference numeral 268. Be- 
low that area is an area designated as the general 
display area, given reference numeral 270, which 
may preferably contain other market related in- 
formation, such as the REUTER MONITOR page. 
The same areas are preferably provided in the 
screen layouts illustrated in Figs. 11 and 12 with, 
however, the size of the general display area 270 
being increased so as to provide more room for the 
general display area 270 in the screen layout in the 
integrated screen display 238. As can be seen in 
Figs. 11 and 12, which relate to the same, screen 
layout in which the general display area 270 is 
larger, such as 14 rows as compared with the 9 
rows provided in the example of Fig. 10, the larger 
size for the general display area 270 is accom- 
plished preferably by overlaying the matching trade 
area 260 and the conversational trade area 264, 
with Fig. 11 illustrating the screen layout when a 
matching trade option has been selected by the 
integrated keystation and with Fig. 12 illustrating 
the same screen layout when a conversational 
trade option has been selected by the integrated 
keystation. In this regard, it should be noted that in 
the option illustrated in Fig. 11, the conversational 
trade area 264 is, by way of example, 15 rows in 
height, and the matching trade area 260 is 7 rows 
in height, whereas in the option illustrated in Fig. 
12, the conversational trade area 264 has been 
increased to 22 rows, by way of example, by 
overlaying the 7 rows previously used for the 
matching area 260. Thus, as previously mentioned, 
the integrated keystation toggles between the 
screen layout of Fig. 11 and the screen layout of 
Fig. 12 depending on the trade option selected by 


the integrated keystation. With respect to the 
screen layouts illustrated in Figs. 13 and 14 for the 
integrated screen display 238, these screen layouts 
preferably have the same windows as the afore- 
5 mentioned screen layouts with, however, the num- 
ber of rows in various areas being reduced so as to 
accommodate larger characters in the display. In 
this regard, in Fig. 13, which illustrates the in-, 
tegrated screen display 238 layout when matching 
io has been selected, the incoming calls area 266 is 
reduced in size as is the conversational trade area 
264, and the general display area 270 is the same 
size as in the option of Fig. 10. In Fig. 14, when the 
conversational trade option has been selected, the 
75 matching trade area 260 is overlayed by the con- 
versational trade area 264 which is increased in 
size, by way of example, from the 6 rows of Fig. 13 
to 13 rows in Fig. 14, and the incoming calls area, 
which is also used for conversation analysis sum- 
20 mary, 266 is increased in size. Preferably, the 
integrated screen display 238 has a high resolution, 
such as 640 pixels horizontally by 480 pixels verti- 
cally, which is in line with the normal VGA stan- 
dard, with the video being conventionally supplied 
25 by a Windows 386 driver and the STB VGA card in 
the terminal computer 250. 

Referring now to Fig. 15, an integrated key- 
board 240 contains keys which will enable the user 
to participate in both matching trades as well as in 
30 conventional trades in the system 200. For exam- 
ple, such a keyboard 240 may be obtained from 
Reuters, the assignee herein, under the designation 
DK101 or AK122/3, with all of the integrated key- 
boards 240 on a particular integrated terminal con- 
35 troller 214 preferably being of the same type. The 
system 200 uses keep alive signals from the in- 
tegrated keyboard 240 in order promptly to detect 
keyboard failure since such failure would effectively 
mechanically disable the trader or keystation from 
40 participating in both matching and/or conversational 
trades through use of the system 200. The keep . 
alive signal is preferably a special character which 
is sent to the terminal computer 250 of the keysta- 
tion, at a predetermined periodic interval, such as 
45 every 4 or 5 seconds. This procedure is diagra- 
matically illustrated in Fig. 27. When the terminal 
computer 250 receives these special keep alive 
character, it preferably increments a keep alive 
counter, with this procedure being illustrated in Fig. 
so 28. The terminal computer 250 also preferably 
checks at a periodic interval, such as every 5 
seconds, whether the keep alive counter has been 
incremented. If the counter has not been incre- 
mented from the previous count, this indicates to 
55 the terminal computer 250 that the keep alive sig- 
nal or special character has not been received and 
that, consequently, the integrated keyboard 240 
may have failed. This procedure is illustrated in 
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Fig. 29. When me terminal computer 250 detects 
that the keyboard 240 has tailed, me keystation 
removes ail entries which >! has pfaced in the 
matching market in connection with potential auto- 
matic matching trades 3nd automatical/ terminates 
ail its current conversations associated with con- 
versational trading, and togs off. if desired, an 
al3rm can also be provided at the keystation on the 
screen 238 indicating thai the keyboard has failed. 
Thus, the keep alive signal periodically provided 
ftom the integrated keyboard 240 provides a heart- 
beat from the keyboard 240 to the terminal com- 
puter 250. which has been conventionally pro- 
grammed in accordance with the procedures illus- 
trated in Figs. 28 - 29, and which automatically 
removes the offers and bids associated with that 
keystation from the matching host computer 224 
when it is detected that the integrated keyboard 
240 has f3iieci by failing to provide an appropriate 
heartbeat or keep alive signal to the terminal com- 
puter 250- Summarizing the above, when a keep 
alive signal is not provided and the terminal com- 
puter 250 detects that it has not been provided 
because the keep alive counter has not. been incre- 
mented, iour actions occur; namely, the user is 
informed that the keyboard 240 has failed, the user 
is logged of? the keystation, contact is ended in alt 
conversations which were active at the time in the 
conversational trading portion of the integrated 
trading system 200. and all prices which had been 
input to the matching host computer 224 by that 
keystation in connection wish the automatic match- 
ing trading portion of the integrated system 200 ate 
automatically removed from she matching host 
computer 224 database. Preferably, as shown and 
preferred in Fig. 29. if a keep alive signaf is not 
detected in the first instance, then the tormina! 
computer 250 retries again. If it is not detected 
after she second try, or second beat, then the 
terminal computer 250 indicates that the keyboard 
240 has failed, in this regard, if a mouse 242 is 
provided a! the keystation, preferably, the keysta- 
tion may continue to operate if the mouse 242 fails 
as iong as the integrated keyboard 240 is still 
functioning. 

The function of logging on to she matching 
communication network 220 tn order to effect auto- 
matic matching trades and to the conversation 
communication network 218 in order to effect video 
conversational negotiated trades is integrated m the 
system 200, Fig. 18 is a state diagram illustrating 
the sequence of operations in connection with the 
integrated log on/log off to the system 200, with 
Figs. 19-20 illustrating a logic flow diagram of the 
logic operations performed by the system 200 in 
connection with the sequence of operations illus- 
trated in Fig. 18. preferably, in order for the user or 
keystation to log on to the system 200, a user 


identifier is required as we!! as. preferably, a user 
password. Preferably, the user identifier is part of 
the set up data in the integrated terminai controller 
214 and must be entered correctly on fog on for 
5 the user. When Ihis information is entered, the 
server database 262 and the integrated terminal 
controller 2t4 is accessed in order to obtain the 
subscriber name and lo check the user 5.D. !f the 
user i.O. is known in the system 200, then the 
to terminal or keystation 202. far example, is checked 
to see ii it has been permissioned for matching if it 
has, then the mtegraied keystation, 202 by way et 
example, tries to log on to the matching commu- 
nication network 220 with the input password, su ta- 
rs scriber name and user f.O. If k>g on succeeds to 
the matching communication network 220 the 
keystation 202 has now been logged on to both the 
conversation communication network 218 and the 
matching communication network 220, since log on 
so to the conversation communication network 218 
has nol been inhibited. IS, however, the keystation 
202 cannoi fog on to the matching communication 
network 220, then the keystation 202 is preferably 
disconnected from both the matching comrnunica- 
25 tion network 220 and the conversation communica- 
tion network 218 and the log on procedure is 
repeated, starting with the insertion of the user i.D. 
and password, if, however, matching communica- 
tion for the keystation 202 is not enabled, as op- 
jo posed to attempting to log on and faffing to log on, 
then conversation communication may still be en- 
abled with ihe conversation communication network 
218. 

Referring to the log off procedure, assuming 

;?s matching communication has not been enabled but 
conversation communication with the conversation 
communication network 218 had been enabled at 
the time of the log off request, then the system 200 
checks to see if a conversation is m progress, tf a 

4.0 conversation is in progress then the keystation. 202 
may not log oil However if a conversation is not in 
progress, then the Keystation 202 may be discon- 
nected from the conversation communication net- 
work 2i8- Similarly, if matching communication had 

4$ been enabled and the keystation 202 had logged 
on to both the matching communication network 
220 and the conversation communication network 
2t8, the keystation 202 stifi could not tog off if a 
conversation was in progress with that keystation 

so 202 The keystation 202 would have to first termi- 
nate the conversation. Furthermore. 3S shown and 
preferred in Fig. 20, if a fog off request were 
received from that keystation 202 which had been 
fogged on to both the communication network 220 

ss and She conversation communication network 218, 
then the system 200, and particularly the asso- 
ciated integrated terminal controller 214, would first 
determine whether any trading conversation or 
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matching was in progress associated with thai 
keystation 202 and, assuming it was not then in 
progress, the terminal controller 214 would then 
determine whether there were any outstanding 
matching tickets expected as a result of trades 
which had been completed but had not yes had a 
ticket generated, ff there were no outstanding 
matching tickets expected, then the keystation 202 
could disconnect from both matching and con- 
versations! trading, if however, there were outstand- 
ing matching tickets expected, then preferably the 
user, would be given the option to confirm a tog off, 
or cancel a log off, or wait for the tickets. If the 
user confirmed a log off ot had received 'tie tickets 
after watting for them, the user could then dis- 
connect ftom matching and conversational trading, 
if the user merely cancel led She log off. then 
conversation and matching trading would still be 
enabled. This would also be true if a conversational 
or matching trade associated with that keystation 
were stilt in progress. As also shown and preferred 
in Fig. 19, if the keyboard 240 either tailed in any 
state in the sequence of operations or was discon- 
nected duiing any state in the sequence of oper- 
ations, the keystation 302 would be disconnected 
from both matching and conversation at trading until 
reconnection of the keyboard 202, tt should be 
noted from the above, that a keystation 202 may 
soleiy log on to conversational trading or automatic 
matching trading if thai is its capability or desired 
intent. The purpose of the integrated log on is to 
enable a single keystation 202 to log on to both 
different types of trading systems, assuming it has 
that capability . with a single log on procedure The 
software associated with the log on/log off proce- 
dure illustrated in Figs. ?8 - 20 Is contained, by 
way oi example, in Table A annexed hereto as an 
Appendix, and is written in C language for use with 
the 8G3S6 terminal computer 250 in which this 
software is resident. 

Referring new to Figs. 21 - 24. typicaf screen 
displays far the integrated screen display 238 are 
shown which contain trading information in connec- 
tion with both matching trades and video conversa- 
tional negotiated trades by the keystation 202 after 
it has lagged on to both the matching communica- 
tion network 220 and the conversation communica- 
tion network 2i3, Fig. 2i illustrates the presence of 
both conversational trading data and matching trad- 
ing data on the integrated screen display 238. Fig. 
22 illustrates the same Integrated screen display 
238 when the YOURS key on the keyboard 240 of 
Fig, 15 has been depressed and the YOURS dia- 
logue box is about to be transmitted. Fig. 23 illus- 
trates the same integrated screen display 238 
when a matching trade has been automatically 
executed and a maxch notification has been pro- 
vided from the matching host comouter 224 to the 


integrated terminal controller 214 associated with 
the keystation 202. The fogtc flow diagram illustrat- 
ing the operation of the integrated terminal control- 
ler 214 in response to such a match notification is 

s shown in Fig. 25 to be described in greater detail 
hereinafter. Fig. 24 illustrates the same integrated 
screen dispfay 238 with, this time, a conversational 
negotiated trade having been completed as shown 
on the screen and in the conversation analysis area 

jo 266. 

The logic flow diagram of Fig. 25 may be 
accomplished by conventional programming of the 
integrated terminai controller 214. When the match 
acknowledgment, to be. described in greater detail 
rs with reference to Fig. 9 and EP-A-90305753 is 
received from the matching host computer 22*. the 
match is displayed on the integrated screen dis- 
pfay 238 which was a party to the matching trans- 
action, fn addition, an audit trait message is sent to 
so the database server 552 which forms part of the 
conversation server 252 ot the integrated terminal 
contoriler 214 and the audit trail is stored at the 
database server 262. A repiy with the match num- 
ber is sent to the keystation and when the match 
ss number is received by the keystation 202 a match 
acknowledgement, termed MATCH ACK, is sent to 
the matching host computer 224 As further shown 
and preferred in Fig. 25. the database server 282 
may afso be preferably connected to the audit trail 
30 printer 280 lor printing of audit messages. The 
procedure for printing such audit traii messages is 
also illustrated in the logic flow diagram of Fig. 25. 

Fig. 28 is a logic flow diagram of the operation 
of fhe integrated terminal controller 2t4 in re- 
35 sponse to receipt of a matching ticket Of conversa- 
tion ticket st the completion ot an automatic match- 
ing trade or video conversation negotiated trade, 
respectively, and may, of course also be imple- 
mented by conventional programming of the in- 
40 tegrated terminal controller 214. when a march 
ticket is received at the integrated keystation 202 
from the matching host computer 224, the match 
ticket is sent to the database server 262 contained 
m the conversation server 252 of the i migrated 
45 terminal controller 25 4 in the form of what >s 
termed a pssudo conversation, with a typical 
matching ticket corresponding to such pseutio con- 
versation being illustrated in Fig IS. This match 
ticket is then stored at the database server 262 and 
$q can be accessed to support review of displays on 
the integrated screen dispfay 238 via the terminai 
computer 250 or to support retrieval of tickets over 
the ticket output feed 234 to the back office com- 
puter. Similarly, when a conversation ticket is ccn- 
ss firmed at the completion of a video conversational 
negotiated trade, the conversation ticket, which 
may be in the form shown by way of example in 
Fig. 17. is sent to the database server 282 con- 
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sained in the conversation server 252 of the in- 
tegrated terminal controller 214 along with tha con - 
versation, the ticket is then stored at the database 
server 282 with ihe conversation and, like the 
matching ticket, may be accessed to support re- 
vtew of displays on the integrated screen display 
238 via the terminal computer 250 and to support 
retrieval of tickets over the ticket output feed 234. 
Fig. 28 also Illustrates the operation or the printing 
of a ticket, either a match ticket or a conversation 
ticket, by the ticket printer 226 utilizing the ticket 
data stored at the database server 262. 

Apart from the differences described above 
with respect to the emptoyment of the integrated 
terminal controller 214 and integrated keystation 
202 so as to enable the integration of automatic 
matching trades and video conversational negoti- 
ated trades in the system 200, the function and 
operation of the various components of the system 
200 relating to ihe conversation commnication net- 
work 2 58 and matching communication network 
220 are preferably the same as described in the 
respective aforementioned patents and EP and GB 
specifications which relate to these functions How- 
ever, for purposes of clarity, certain portions of 
these patent applications shall be repeated herein 
with respect to figs. 3 and 4 relating to video 
conversational negotiated trades; Figs, 7-9 and 30 
relating to automatic matching trades; and Figs. 31- 
34 relating to the ticket generation scheme for 
providing (tie ticket output feed via path 234 or 
2:36. 

Referring now to Figs. 3 and 4, as previously 
mentioned, the integrated trading system 200, pro- 
vides conversation analysis with respect ro the 
video conversational negotiated trades effected by 
the system 200, with this conversation analysts 
being summarized in area 266 ot the integrated 
screen dispiay 238. This analysis is preferably ac- 
complished in the same manner as described in 
the aforementioned GB-A-2.226,217, in which con- 
text sensitive prompts are employed, with the con- 
versation analysis software driving the analysis 
driven prompts and letting the user know in real 
time where the user is in the conversation that is 
going on between counterparties, such as foreign 
exchange traders, so thai the appropriate prompt 
selection menu may be employed based on the 
analysts of the key points in the conversation as if 
proceeds in real time. This real time conversation 
analysis, as described m GS-A-2,226,2! >\ also en- 
ables ihe preparation of Dealing or conversation 
tickets in reaf time white the deat is being arranged 
through the use of artificial intelligence techniques 
to analyze ths conversation dialog and generate 
the ticket. Thus, as described in G8-A-2,226.2i 7, 
this is accomplished m an expert type of system. 
The context sensitive or analysis driven prompts 


are preferably employed to speed up the dealer 
input in connection with video conversational nego- 
tiated trades in system 200 of the present invention 
since time is generally of the essence, such as in 

i foreign exchange dealings. Of course, the system 
20Q need not be limited to foreign exchange deal- 
ing and may be used in connection with any type 
of video communication where rapid input of con- 
versation information is desired. Of course, as is 

to also described in GB-A-2.226.ai7.. she system may 
bo employed for data capture of offline deals as 
well. Because of this conversation analysis, the 
system 200, is capable of generating error mes- 
sages lo the user to alert the user if an tnconsis- 

?5 tency is detected in the conversation being ana- 
lysed in connection with a video conversational 
negotiated trade, such as if the value date is in- 
proper or the range of prices is ioproper. by way of 
example. As described in GB-A-2,226.25 7, apart 

so from the conversation analysis driven prompts and 
associated features, the system is substantially 
similar to other conversational video systems de- 
veloped by the assignee herein arid described in 
the aforementioned GB-A-2,227,625. In mis regard.. 

i's the conversation communication network 218 is 
preferably basically the same type of communica- 
tion network as illustrated in Fig. 13J, by way of 
example, of US-A-4,525,779 and the same refer- 
ence numerals have been used in Fig. 4 as are 

so used in tJS-A-4,525,779 for like functioning compo- 
nents such as for the concentrators 48 and 1 1 0, 
and for the nodes 44 and 42, but with the host 
computer given reference number 38 in Fig. 13J, of 
US-A-4.525.779. and with the storage device hav- 

55 ing been given reference numeral 205 in the exam- 
ple of Fig, 4. The London Taker in Fig. 4 is 
assumed to be the integrated terminal controller 
216 at client site 252 and ths New York Maker is 
assumed to be the integrated terminal controller 

40 2t4 at client site 210. Of course, other packet 
switching communication networks could be em- 
ployed for the conversation communication net- 
works 218 in place of the network illustrated in Fig. 
4. The terminal controller shown in Fig. 13J of US- 

45 A-4.&25.779 is replaced 0y Ihe integrated terminal 
controller 214 or 216 in the system of Fig. 1, with 
this integrated terminal controller preferably includ- 
ing a conversation analysing terminal controller 
portion 214a, such as illustrated in Fig. 3. which 

so enables real time conversation analysis of the vid- 
eo conversations between, for example, the New 
York Maker at client site 2iQ and the London taker 
at client site 21 2, and the provision of context 
sensitive analysis driven prompts. In this regard, 
and as described m the aforementioned GA- 
2.227,625, conversation tickets may be printed 
based on real lime conversation analysis, in addi- 
tion, as was also previously mentioned, the in- 
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fegraled keystations 202. 204, 208. 208 preferably 
also have a conventional mouse 242. such as the 
mouse described in the aforementioned Qb-A- 
2,227,635. such as tor providing the fast contact 
features described therein and illustrated in Figs. 
35-36 which correspond to Figs. 11-12 of G8-A- 
2,227,825. If these features are not desired, the 
mouse 242 may be omitted. Moreover, it should be 
noted, that both parties io a conversation need not 
have an integrated terminal controller 214. 256 
containing a conversation analyzing terminal con- 
troller portion 214a, m that the analysis server 264 
may be omitted, however, the party will then not 
nave the benefit of real time conversation analysis 
to provide context sensitive or analysis driven 
prompts or automatic ticket generation or inconsis- 
tency notification based on such ret:! time con- 
versation analysis. 

With respect to the conversation anayiztng ter- 
minal controller portion 214a illustrated in Fig. 3, 
the Sine server 260, database server 262 and con- 
versation analysis server 264 are all preferably 
80386 computers, such as a COMPAQ 80386 
based computer. In addition, as was previously 
mentioned, the terminal computers 250 are also 
preferably 8Q38S based computers, each ot which 
provides outputs to its associated integrated screen 
display 238, integrated keyboard 240. and mouse 
242. The previously mentioned local area network 
256 further permits communication between appro- 
priate ones Of the various computers 260, 262. 252 
and 250 in accomplishing the conversation analy- 
sis, context sensitive prompts, inconsistency alert, 
and automatic ticket generation functions of the 
system 200. The line server 260 preferably serves 
as an interface between the terminal computers 
250 and the appropriate concentrator 43 or HO in 
the conversation communication network 218. The 
functions of the database server 262 have already 
been described with respect to the integrated ter- 
minal controifer 214. As for the conversation analy- 
sis server 264, this server 264 preferably stores the 
conversation analysis software, such 3S the soft- 
ware described m derail in ihe aforementioned G8- 
A-2.227,625 and analyzes the conversation m real 
time and provides the desired context sensitive or 
analysis driven prompts to the Maker or Taker's 
screen 238. depending on whom the conversation 
analysing terminal controller portion 214a is asso- 
ciated with at the time, provides conversation tick- 
ets to the datsoase server 262 associated with it, 
and alerts ihe user to inconsistencies in the con- 
versation by providing such alerts to the Integrated 
screen display 238. Ol course, although in the 
example of Fig, 3. separate servers 28G, 262 and 
284 are shown as comprising the conversation 
server 252 of the integrated terminal controller 214, 
these servers can be combined into a single com- 


puter, if desired, with each keystation 202, 204, 
208, 208 stiH being supported by a dedicated ter- 
minal computer 250 and with, as previously men- 
tioned, these keystation terminal computers 250 

5 being linked to the servers 260, 262, 264 by the 
conventional Iocs! area network 258. Preferably, 
communication over this local area network 256 
uses a virtual connection such as provided by the 
MS-NET standard variant. In addition, preferably a!i 

w of the data about each conversation in progress, 
such 3s up to 24 such conversations for a given 
terminal controller 2*4, by way of example, is held 
in a global array with each element in this array 
pointing to a structure of type CONVDATA in ac- 

?5 cof dance with the software illustrated, by way of 
example, in the aforementioned GB-A-2.227,825. 
This is a typo which holds the various network 
handles associated with the conversation, the text 
buffer for the conversation, and so on. It also 

so preferably includes an element identified as 
SAVEDOATA of type ANALYSiSDATA, which is 
used to store the state of the conversation analysis. 
The conversation analysis is driven by the receipt 
of packets of text from the various keystations 202, 

2$ 204, 206. 208 comprising the subscriber population 
of the conversation communication network 2t8. 
These successive chunks of text arrive in AN- 
ALYSE TEXT PACKETS which are directed to the 
correct procedure by the environment, which has 

:>o been informed of the destination of the input mes- 
sages by a call to NetRegisterRepiy in the proce- 
dure Ov-main in section caserver.c in the software 
described in the aforementioned GB-A-2,227,825. 
The incoming packets of text are directed to the 

as procedure fn ReplyAnaiysisMessagas In the sec- 
tion camesage.c. When an ANALYSE TEXT packet 
is received for a conversation. (Current Conv) is set 
io point to the CONVDATA structure tor the appro- 
priate conversation, and the saved analysis s^ate 

<jo arid ticket are preferably copied into the working 
areas pointed to by the global s (Ticket) and 
{Analysis Data). Then the procedure Re- 
pfyAnalyzeText in tne section camesage.c of the 
software described in the aforementioned G8-A- 

*s 2,227.625 is called to check the request. If appro- 
priate, the analysis is initialized. This happens 
when text is deleted, for example, by an interrupt. 
Any new text is added to the conversation and the 
C library procedure setjump of the aforementioned 

so software Is called to store the current C context for 
the Icngjurnp return from parsing. This call to set- 
lurnp returns ze;o, and then the parsing routine 
parse of She aforementioned software is preferably 
called to analyse the conversation from the last 

55 saved state. When the parsing is terminated by 
reaching the end of the text currently held, the 
longjump call returns to She point at which saijomp 
was called with a non sero reply, and the analysis 
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is wrapped up by notifying the keystation 202, by 
way of example, of any change to the analysis. 
Preferably, the conversation analysis, such as ex- 
emplified by the software described in the afore- 
mentioned GB-A-2,227,625, always starts on the 
parse procedure. 

It should be noted, as described in the afore- 
mentioned GB-A-2,227,625, that preferably conver- 
sation analysis is performed on words or groups of 
symbols which are extracted by nextsym in section 
read.c of the conversation analysis software listing 
described in the aforementioned GB-A-2,227,625. 
Thus, until the conclusion of a stage of analysis, 
the symbols found are preferably stored in a buffer 
so that the analysis can backtrack if the current 
hypothesis proves incorrect; if a reanalysis is in 
progress, and there is such a queue of extracted 
symbols, nextsym preferably selects the next item 
in the queue. Otherwise, nextsym preferably reads 
a symbol from the text using the routine readsym 
described in the aforementioned software, which 
procedure preferably obtains characters from the 
text buffer using the routine readch. At this stage, 
fully replaceable synonyms, such as PLEASE and 
PLS, are merged to a single symbol code, held 
under the identifier (symbol). Other words are pref- 
erably allocated to a symbol such as S currency 
and individually identified by a number held in 
(symval). In the case of a currency identifier, this 
preferably identifies the actual currency, assuming 
that the conversation is being employed for foreign 
exchange. In addition, as was previously men- 
tioned, the preferred conversation, analysis 
software-described in the aforementioned GB-A- 
2,227,625 includes an error detection procedure 
which checks the deals as they occur in real time, 
reporting erroneous or suspect conditions to the 
user based on analysis of the conversation, with 
the error messages preferably being placed below 
the insert line in the integrated screen display 238 
and the suspect flag data being highlighted in the 
summary analysis display area 266 on the inte- 
grated screen display 238 so as to provide an alert. 
It should be noted that in employing the conversa- 
tion analysis function in the system 200 the general 
display area .270 in the integrated screen display 
238 may be used to display additional financial 
information, such as a REUTER MONITOR page, 
prompt menus, analysis of the conversations, etc, 
with the analysis of the conversations normally 
preferably replacing the REUTER MONITOR dis- 
play. This area 270, may also be used for prompts 
and expanded analyses. With respect to the start- 
ing of conversations in the integrated system 200, 
such conversations can basically be started in 
three ways; namely, the user can contact another 
dealer,, the user can accept the call from another 
dealer, or the user can enter the complete deal, 


using the CAPTURE function, as an offline deal. 
The particular menus displayed, preferably depend 
initially on how the conversation is started, with the 
person making the contact normally being referred 
5 to as the Market Taker and the person accepting 
the contact normally being referred to as the Mar- 
ket Maker. 

With respect to the printing of conversation 
tickets, assuming conversation analysis is em- 

10 ployed in the system 200, the conversation tickets 
are preferably created in the system 200 as the 
system extracts information by analyzing conversa- 
tions, with the display of the ticket being generated 
appearing on the integrated screen display 238. 

75 Preferably, only one analysis can be associated 
with one conversation and, after a user confirms 
the analysis with respect to a current conversation, 
a ticket can be printed on the ticket printer 226 
depending on whether it. is the Market Maker or the 

20 Market Taker, respectively, when the conversation 
is next terminated or printed. Preferably, the ticket 
printer 226 has the same characteristics as the 
conversation printer 230; namely, it accepts serial 
data and it prints on continuous paper. As a con- 

25 versation takes place, the associated conversation 
analysis area on the integrated screen display 238 
preferably shows a summary of the analysis in- 
formation which, if desired, can become a fully 
expanded version of a current analysis which is 

30 then displayed in the general display area 270. 
When the conversation is terminated and saved, 
preferably the analysis is saved with it. Preferably, 
conversations and analyses are saved and deleted 
only as more storage is required. Before conversa- 

35 tion analysis can be confirmed, however, preferably 
it must contain at least the following information 
about the deal: the deal type, the deal direction, 
the currency or currencies, the amount, the rate or 
rates, and the value date. Thereafter, the user can 

40 confirm the conversation analysis by pressing the 
CONFIRM key on the keyboard 240. Once an 
analysis has been set into the confirming mode, 
the next time the conversation is ended on the 
dealer's screen 238, a ticket is preferably printed 

45 and, thereafter, the conversation cannot be edited 
any further. If the analysis has not been confirmed, 
it can be marked as cancelled or wrong at any time 
during a real or offline conversation or when wrap- 
ping up a conversation by pressing the CANCEL or 

so WRONG keys on the keyboard 240. Thus, in order 
to generate a ticket on the ticket printer 226 asso- 
ciated with a video conversational negotiated trade, 
the conversation being analyzed is set to the CON- 
FIRMING state which ends the analysis. 
55 Although a more detailed description is includ- 

ed in EP and GB specifications, particularly EP-A- 
90305753, the automatic matching trade compo- 
nent will be briefly described with reference to 
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Figs. 7-9 and 30. In this regard. Fig. 7 corresponds 
io Fig. 1 of EP-A-903057&3. with the matching 
communication outwork 220 corresponding to refer- 
ence numeral 22 in Fig. f of this publication, and 
wiih the central matching host computer 224 cor- 
responding to reference numeral 20 in Fig. i of this 
publication, in addition, the client sites in F;g. 7 
have teen given reference numerate 210 and 212 
as opposed to the reference numerals 28a and 26b 
employed in Fig. i of this publication, since these 
client sites 210, 2t2 contain the presently preferred 
integrated terminal controllers 214. 218, and with 
the keystations 24a and 24b of Fig., t of this 
publication being replaced by the presently pre- 
ferred integrated keystations 202. 204. 206, 208. 
Similarly. Fig. 8 corresponds to Fig. 2 of this pub- 
lication with the same exceptions, and Fig. 9 cor- 
responds to Fig. 3 of this publication with the same 
exceptions Similarly, fig. 30 corresponds to Fig. 6 
of this publication with the same exceptions with 
respect tG the integrated keystations 202 and 206 
being substituted for keystations 24a and 24b, and 
wiih the reference nunier.a! 224 being used for the 
centra) matching host computer 20 employed in 
Fig. 6 of tnis publication. As shown and preferred 
Fig. 8, the matching component for effecting auto- 
matic matching trades in the integrated trading 
system 200 is shown in which trading is effected 
through anonymous matching as opposed to 
through the previously described video conversa- 
tional negotiated trades. Thus, in connection with 
the distributed matching communication network 
220 of the system 200. the matching host com- 
puter 224 servos as a computerised exchange in 
which its centra! role 15 -o Identify a buyer and 
sefler who are willing to trade with one another 
based on specified criteria, such as price, quantity 
and credit. When such a matching event occurs, 
assuming the integrated keystation 202 has logged 
on to the matching communication network 220 in 
the manner previousfy described with reference to 
Fsgs. 5 8 ■■ 20, preferably the buyer and seller are 
informed of the trade and sufficient information is 
•hen provided to them through the respective in- 
tegrated terminal controllers 214 and 2i6 in order 
to compiste the physical clearing of the transaction. 
As described in the aforementioned EP and OB 
specifications, in order to support this central func- 
tion, various support functions are required, one of 
which is preferably the maintenance of summary 
market information on the participant's keystation 
integrated display 238 at the various client sites 
210. 212. Preferably, at all times, those keystations 
202, 20-1, 206 and 208 which form part oi the 
matching communication network 220 wiil display 
the best inside price for every instrument traded 
through that network 220. Aithough all four keysta- 
tions 202, 204, 206, 208 are represented as being 


pari of the matching communication network 220. 
as well as being part of the conversation commu- 
nication network 2s8, this need not be the case. 
The best Inside price is preferably defined to be 

5 the highest value bid and the lowest value offer in 
the network 220. Preferably, fhe prices are dis- 
played together on the integrated screen display 
23S with the quantity bid or offered at the specified 
price so that the trader at the respective integrated 

to keystation 202. 204, 206. or 208 can observe the 
market activity. By observing the market activity. 
She trader can decide whether to enter a bid, or 
enter an offer into the market in an effort to com- 
plete a matching transaction, as opposed to the 

;5 manner of openly negotiating a trade by exchang- 
ing discretionary messages through the conversa- 
tion communication network 218 to complete a 
video conversational negotiated trade. Thus, with 
respect to the client site 2f0 or 212 to the central 

20 matching host computer 224 will preferably result 
in one or more messages, represented by refer- 
ence numeral 32. going directly back as a directed 
message to the ciiem site, 210 in this example, 
which initiated tho transaction message. Another 

25 effect oi the transaction message 30 being sent to 
the centra! matching host computer 224 is that for 
certain sorts of transactions, a broadcast message 
34 is generated by the centra! matching host com- 
puter 224 which is then delivered to ail client sstes 

-jo 2 10, 212 attached to the central matching host 
computer 224 via the matching communication net- 
work 222. Thus, the directed response or the d'h 
rected message 32 only goes back to the particular 
client site 2i0 and. more particularly, the particular 

35 integrated keystation, 202 by way of example, at 
that client site 210 which initiated the transaction 
message, whereas the broadcast message, 34 
goes to all client sites 2f0, 212 and all the various 
integrated keystations 202 , 204, 206, 208 assc- 

40 dated at those client sites 2 50, 212 which are part 
of the matching communication network 220. As 
was previously mentioned, by way of example, in 
Fig. 7. a typical client site 210 is shown as having 
keystations 202 and 204, aithough the number of 

-is keystations available at a client site is merely limit- 
ed by the capacity of the system and the desired 
processing time. With respect to the distribution of 
the functionality in connection with the matching 
communication network 220 of the integrated trad- 

so ing system 200, the matching communication net- 
work 222 preferably does not really play a pari in 
that it'is transparent to transactional information. By 
this what is meant is that when the transactional 
information leaves the client site 250. for example, 

55 it could be, if desired, encrypted or garbled in a 
way that the only other entity which could under- 
stand it would be the centra! matching host com- 
puter 224 and that would be irrelevant to the func- 
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tion of the matching communication network 222 
since the network does not look at the messages, 
does not process the messages, and merely trans- 
fers these messages to the appropriate parts of the 
matching communication network 220, matching 
communication network 220, the system 200 es- 
sentially maintains a book of bids and offers in the 
matching host, computer 224 and a user or keysta- 
tion 202, 206, by way of example, and a client site, 
such as client sites 210 and 212, respectively, 
interacts with the book by submitting bid, offer, hit, 
or take transactions, such as illustrated in Fig. 8. 
The order entry function is preferably convention- 
ally achieved through data entry using the inte- 
grated keyboard 240, the mouse 242, or any other 
conventional data entry tool. The matching host 
computer 224 validates the transaction request, 
processes the bid, or the hit or take, according to 
the rules of the market, and attempts to find match- 
es between this new entry and the other bids or 
offers posted in the matching communication net- 
work 220 book. If a match is found, then the trade 
is automatically executed, the participants to the 
trade are informed, all databases and trader 
screens 238 are updated as to the quantities traded 
and the quantities remaining and, if desired, a 
clearing agency may be informed as to the details 
of the trade so that payment and exchanges may 
be completed. If on the other hand, a match can 
not be found, then the matching communication 
network 220 preferably either disposes of the entry 
for hit or take or keeps the entry for bid or offer for 
later processing. Preferably, in all cases, transac- 
tions are processed to completion according to 
certain rules and the various client sites 210, 212 
preferably receive real time updates of the new 
status of the trading instruments, assuming that 
they are members of the matching communication 
network 220. Thus, as shown and preferred in Fig. 
8, the client site systems 210, 212, only two of 
which are shown by way of example in Fig. 8, 
when the associated keystations 202, 204, 206, 208 
have selected the matching trade option, submit 
transactions, such as represented by reference nu- 
meral 30 in Fig. 7, to the central matching host 224 
via the matching communication network 222. 

As will be explained in greater detail hereinafter 
with reference to Fig. 30, the submission of a 
transaction 30 from a 


such as to the matching host computer 224. In this 
regard, the network 220 is functioning similar to a 
paired cable in that it is there to pass the informa- 
tion back and forth. Of course, the network 220 has 
various other-communication functions which, how- 
ever, for purposes of understanding the matching 


component of the integrated system 200, are un- 
necessary to go into. Suffice it to say that prefer- 
ably the matching communication network 220 
uses a protocol which can be termed hierarchal 
5 fan-out in which one node transmits to multiple 
nodes which in turn transmit to multiple other 
nodes. Thus, matching communication network 220 
helps implement broadcast capabilities integrated 
with a message switching network to achieve full 
w tolerance in broadcast distribution. It should be 
noted, when a match occurs, the central matching 
host computer 224 will preferably send directed 
messages or responses to all of those parties in 
the system 200 that were involved in the match, so 
?s that, in some instances 2,3 or more client sites 
210, 212 may be involved in receiving the directed 
message. However, this still differs from the broad- 
cast message which is sent to all client sites ir- 
respective of their involvement in a particular 
20 match. 

Referring now to Fig. 8, this figure illustrates a 
typical data flow in the integrated system 200, for 
the entry of a bid or entry of an offer, with the 
matching communication network 220, as was pre- 
25 viously mentioned, being transparent to transac- 
tional information Integrated keystation 202, by way 
of example, submits a bid transaction to the central 
matching host computer 224 through the matching 
communication network 220, via the terminal com- 
30 puter 250 and the concentrator computer 254. The 
directed message or directed response 32 which it 
receives back from the central matching host com- 
puter 224 is termed a bid acknowledgment or BID- 
ACK. This acknowledgment is a command ac- 
35 knowledgment which is preferably followed by an 
entry position message and is, as previously men- 
tioned, directed directly back to the keystation 202 
via the concentrator computer 254, the local area 
network 256, and the terminal computer 250. In 
40 addition, as shown and preferred in Fig. 8, a bid 
update message is broadcast by the central match- 
ing host computer 224 to all keystations 202, 204, 
206, 208 in the system 200 which have logged on 
to the matching communication network 220, such 
45 as represented by reference numeral 34a in Fig. 8. 
This broadcast message 34a preferably occurs if 
this new bid 32a was a new best bid in the system 
200 with respect to the matching component, or 
was an additional quantity being bid at the best 
so price in the system 200 with respect to the match- 
ing component. Thus, if this new bid 32a is at the 
highest price or better or higher, then it will result 
in a bid update broadcast message 34a going out 
throughout the system 200 to all keystations which 
55 have logged on to the matching communication 
network 220. In addition, as also shown by way of 
example in Fig. 8, if it is desired to disseminate an 
external ticker 60, then the ticker information 60 will 
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also be provided of the best bid or best offer. 
Preferably, the same procedure is followed with 
respect to entry of an offer with the messages, in 
this instance, being identified as offer, given refer- 
ence numeral 51, offer acknowledgment or OFFER- 
ACK, given reference number 32b, and the broad- 
cast message for offer update, being given refer- 
ence numeral 34b. 

Referring now to Fig. 9, the data flow in the 
integrated system 200, is illustrated with respect to 
a situation in which there was a hit bid resulting in 
a trade. In this situation, there is substantially more 
activity than the situation previously described with 
reference to Fig. 8. Thus, as shown and preferred 
in Fig. 9, if the integrated keystation 206 submits a 
transaction called "hit bid", represented by refer- 
ence numeral 62, to the central matching host 
computer 224 via the matching communication net- 
work 220, a hit acknowledgment or HIT/ACK, repre- 
sented by reference numeral 64, is provided back 
to keystation 206 as a directed message. At that 
point, the central matching host computer 224 will 
recognize that a match is possible because the "hit 
bid" message says that keystation 206 is willing to 
trade at the bid price. Assuming that credit is OK 
and does not play a role beyond that in this trans- 
action, the central matching host computer 224 
determines that a match is possible but, preferably, 
before committing to the match, it may get in- 
volved in a risk limiting protocol using a transaction 
desk 70, as described in the aforementioned EP 
and GB specifications which determines whether 
the trade is possible, and if so, acknowledges this 
to the central matching host computer 224. Assum- 
ing that a trade is possible, then a match occurs. At 
that point several messages are generated from the 
central matching host computer 224 through the 
matching communication network 220. One of 
these messages is termed the match message, 
given reference numeral 65, which is a directed 
message that goes to the bidder, which in this 
instance is keystation 206, and to the keystation 
202, which originally owned the bid. Thus, in this 
instance directed messages go to more than one 
integrated keystation 202, 206 logged on to the 
matching communication network 220. Preferably, 
every match must be acknowledged so there is a 
match acknowledgment message, MATCH-AG K 
which comes back from the buyer and seller 
keystations 202 and 206 and. is used to determine 
that the match was in fact received correctly and 
that the deal can be considered complete at that 
point. The response of the integrated terminal con- 
troller 214, 216 to such a match notification has 
been previously discussed with reference to Fig. 25 
which represents software resident in the various 
terminal computers 250 associated with the keysta- 
tions and in the integrated terminal controllers 214, 


216, themselves, in the respective data servers 
262, as a result of conventional programming. In 
addition, a broadcast message is generated that a 
trade has occurred which trade update message, 

5 given reference numeral 67, may possibly cause a 
new best bid to occur or could affect the quantity 
or price at the top of the book. Again, if the trades 
and best bids go into the ticker 60, then this 
information is provided to the ticker as well: Simi- 

/o larly, if clearing information is provided to a clear- 
ing house, this too occurs as represented by refer- 
ence numeral 69. In addition, as shown and pre- 
ferred , trade tickets may also be generated, such 
as previously referred to with reference to Fig. 26. 

rs Thus, trade ticket information is also preferably 
provided to the participating integrated keystations 
202, 206 in the above example, so that the trade 
tickets can be generated with respect to the match- 
ing trades. 

20 It should be noted that the concentrator com- 

puterise, which interfaces with the matching com- 
munication network 220, preferably always commu- 
nicates with the associated conversation server 252 
containing the database server 262 which controls 

25 the ticket generation, via the keystation terminal 
computer 250. Thus, the concentrator computer 
254 and the conversation server 252 are tied to- 
gether in the integrated terminal controller 214, 216 
through the local area network 256 and the asso- 

30 ciated keystation terminal computers 250. Conse- 
quently, the software associated with the "ticket 
received" function illustrated in Fig. 26, which may 
be accomplished by conventional programming, is 
resident in the terminal computers 250 associated 

35 with the individual keystations and in the data serv- 
er 262 portion of the conversation server 252 in the 
integrated terminal controller 214, 216. 

With respect to the details of the various books 
employed in the distributed matching component of 

40 the integrated trading system 200, these details are 
described in the aforementioned EP and GB speci- 
fications. Suffice it to say that the central matching 
host computer 224 maintains a host book database 
comprising all of the active bids and offers in the 

45 integrated trading system 200 which have been 
provided by keystations which have logged on to 
the matching communication network 220 and that 
each of the respective integrated keystations 
logged on to the matching communication network 

so 220 has an associated local data base keystation 
book which comprises a subset of the host book, 
with the content of each of the keystation books 
having an associated display depth range control- 
lable by the central matching host computer 224 

55 and being updatable by transaction update broad- 
cast messages received from the matching host 
computer 224 through the matching communication 
network 220. In this regard, reference is made to 
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Fig. 30 which illustrates me two collections oi in- 
formation which are being maintained at the client 
sites 210, 212 which have logged on to the match- 
ing communication network 220. As shown by way 
of example in Fig. 30, one ot these collections ot 
information is me book for each instrument which is 
maintained at the keystation sites. 202 and 206, ih 
the above example , and have been given reisrence 
numerals 112 and 110 respectively m Fig. 30. 
Another book maintained a; each site is a local 
entry data base or order book which has been 
given reference numerals 118 and 114. respec- 
tively, in Fig. 30. As previously mentioned, there is 
also the host or system book data base associated 
with the central matching host computer 224 which 
has been given reference numeral tt8 in Fig. 30. 
Each time a client site 21 0 or 212, by way of 
exampie. starts up as an integrated keystation log- 
ging on to the matching communication network 
220, such as by using the log an software and 
procedure illustrated by way of example in Figs, 18 
- 20 and in Table A annexed hereto as an Appen- 
dix, which is written m C language for use with an 
80386 computer, and which is resident m the termi- 
nal computer 250 of the integrated keystation, the 
integrated keystation which is logging on to the 
system 200 is preferably initially empty and re- 
quests download of the currency active books from 
the matching host computer 224. Preferably, sepa- 
rate books are maintained for each trading instru- 
ment, and each of these books is maintained at a 
given display depth. In this regard, it should be 
noted that an update broadcast message is prefer- 
ably only broadcast when the price information is 
inside the assigned display depth that has been 
assigned by the matching host computer 224 With 
respect to the local entry database or order books 
114, ! 1 6, those order books i 1 4. 1 1 8 are prefer- 
ably updated by directed messages from the 
matching host computer 224 and/or record the 
orders of the pedicular integrated keystation 202. 
206, by way of example, which had been sent to 
the matching host computer 224 through the 
matching communication network 220. in ibis re- 
gard, these order books fi4. ff6 are preferably 
kept current so that there is a listing only of orders 
which are stili present in the central matching host 
computer 224 from the respective integrated 
keystations 202 or 204. by way of example 

This order database 1 14 and 118 gets modi- 
fied, such as through the removal o! data, due to 
various occurrences, such as when a complete 
match has occurred for a given order and an entry 
remove message is provided, or if it is a partial 
match you may get an entry message that teils you 
that only a partial match h3S been don© against 
that order The match notification, which was pre- 
viously referred to, pteferably refers to a particular 


order that is contained m the order database 114 or 
1 1 8 and indicates what quantity or portion of the 
order has been matched, if ail of the order has 
been matched, the entire order is then preferably 

s deleted from the respective order database M4 or 
116. By way of example, if a bid were put m tor ten 
million yen at a price of 127 and the display was 
enabled, that is the display depth was set to some- 
thing greater than or equal to one, then She central 

70 matching host computer 224 would preferably con- 
struct a broadcast message, which is the afore- 
mentioned update broadcast message, which 
would inform all client sites 2 5 0,21 2 that a new bid 
had been added to the Yen book, assuming that 

;s were the instrument being traded. The update mes- 
sage would instruct an operation block which would 
say add to index one the ten million at 12™. As for 
the other parameters in the update message, add 
index would equal one, type wouid equal bid, quote 

3i? would equal 127. and quantity would equal ten 
million at 127. As for the other parameters in the 
update message, add index would equal one, type 
would equal bid, quote wouid equal 127 and quan- 
tity would equal ten mtllion. in the above example. 

ss the transaction achieves two functions. The first 
function it achieves is that a bid is submitted and 
the matching host computer 224 responds to the 
integrated keystation 202 submitting She bid that 
the bid was accepted and that there was no am- 

30 biguity m that the bid is definitely in the system 
200; the system 200. namely the matching host 
computer 224, has it; and the ioc3l entry database 
1 1 8 has it. The other function indicates that the bid 
was ot a certain characteristic that the rest of the 

35 "matching trading world" in the system 200 should 
know about, and this is accomplished as a result of 
the broadcast message which was generated to all 
of the client sites 21Q, 2t2 logged onto the match- 
ing network 220. which were then told about this in 

4i? summary as opposed to being given all of the 
detailed information. It should be noted that, as- 
previousiy mentioned, m terms of functional opera- 
tion, the entry of a bid to the system is the sams 
as entry of an offer. 

45 in the situation when a trade occurs, mis 

means that a matching offer is present in the 
system, the matching host computer 224 has ac- 
cepted that matching offer, and sends back the 
acknowledgment command, in effect retrieving the 

so existing book on Yen, in the above example, finds 
out that there is ten million yen at 12? in the book, 
adds to that the newly entered fifteen million at 
*2~. and is aware that it has positioned fifteen 
million at 127 The matching host computer 224 

55 then does the match up inciuding that ten million 
and does the trade, taking out the existing bid. so it 
reduces that amount to zero million at 127 leaving 
over five million at 5 27 on the offer side. In this 
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instance, as will be further explained with reference 
to rig. 30. at least two directed messages have 
been sens, actually four having been transmitted to 
the client sites 210,2t2 that are involved in me 
trade Trie seiler wiii get an indication that his Yen 
bid has traded by means of a match notification 
and he will, thereafter, be informed who the coun- 
terparty was after the match has been made-. The 
clearing and settlement of the trade will then pref- 
erably be the responsibility of the subscribers. The 
counterparty who originally transmitted the offer 
and entry position message saying that it had a 
Yen offer positioned greater than the bid wif! then 
get an entry positioned yen offer at five miliion at 
\27 and wift get a match notification saying that, 
with respect to his offer, ten mtffioo of his origins! 
fifteen million has traded with the parr/ who will 
then be identified. Lastly, the update broadcast 
message will be constructed and broadcast to ail 
client sites 210, 252 togged on to the matching 
network 220 £o update the trading bock. That up- 
date message wiii preferably, in the above exam- 
ple, contain two operation blocks, one which wiil 
remove the bid information from the client book 
and the second which wiii post the new five million 
offer which remains on the offer side and wilt show 
that a trade took place. In addition, as was pre- 
viously mentioned, if desired, ticker information wiii 
also be provided in the update message saying 
what traded, keeping track of the eummulative vol- 
ume, the net change, the number of changes, the 
high limits, the low limits and so forth, ft should be 
noted that preferably only the integrated keystation 
that, either executed the transaction, for example 
keystation 202. or was involved somehow in that 
transaction wiii receive the directed message with 
respect thereto end not other integrated keysta- 
tions, such as keystation 204, at the same client 
site 2i0, whereas with respect to broadcast mes- 
sages ail integrated keystations logged on to the 
matching network 220 at all client sites receive 
these messages, it desired, with respect to credit, 
this can be controlled on a client site by client site 
basis as opposed to a keystation basis. Thus, in 
the system 200, the matching communication net- 
work 220 has two functions, one of which is di- 
rected message defivery and the other of which is 
broadcast message delivery. 

Referring now to Fig. 30 in greater detasi, she 
matching communication network 220 which, as 
was previously mentioned, is transparent to trans- 
actional information, has been omitted 'or purposes 
of explanation of the message flow in the system in 
accordance with the method of the present inven- 
tion. For purposes of the example of Fig. 30. in- 
tegrated keystation 202 can represent any keysta- 
tion which originates a transaction and integrated 
keystation 208 can represent any keystations which 


are involved as counterparties in the transaction 
which, as was previously mentioned can be more 
than one keystation at more than one location. The 
keystations 202 and 206 are normally remotely 

5 located from each other such as, for example, 
keystation 202 being at a client Sits 210 in New 
York and keystation 206 being at. a client site 212 
in London, which are the same locations used in 
the example of Fig. 4 relating to the transaction of 

w video conversational negotiated trades, although 
the iocaticns need not be the same. 

in addition, the keystations 202 and 208 are 
remotely located from the central matching host 
computer 224, in order to understand the message 

rs flow illustrated in Fig. 30, we will assume that the 
originating keystation 202 is receiving a display of 
the keystation bock database located at keystation 
202 on its integrated screen display 238, Assuming 
that the operator at the integrated keystation 202 

so then desires to enter a bid or an offer, either of 
which will be termed an order, this information is 
input to the keystation 202 via conventional means, 
such as the integrated keyboard 240 or a mouse 
242, by way of example. The keystation 202 then 

z$ preferably validates the order and maintains its 
local order data base or focaf entry data base 116. 
The order, instead of being a bid or an offer, could 
be a hit or a take for a particular trading instrument 
as weii since all of these various items would 

so constitute an entry of an order. After the order has 
been entered, validated, and, the order data base 
ri8 maintained, a transaction message is built and 
sent as a directed message to the central matching 
host computer 224 through the matching commu- 

35 nication network 220. This is represented by refer- 
ence nomerai }2C in Fig, 30. This transaction mes- 
sage 120 is received by the central matching host 
computer 224 and contains transaction information. 
At. this point, preferably the central matching host 

to computer 224 sends back a directed message, 
termed a command acknowledgment message and 
given reference numeral 122, to inform integrated 
keystation 202 that the iransaction message 120 
has been received. The transaction message 120 is 

45 time- stamped by the central matching host com- 
puter 224 at this point. Preferably the display 238 
of keystation 202 wilt indicate "please wait" until 
the transaction message 120 has been acknowl- 
edged. Preferably, such acknowledgment happens 

so relatively quickly, such as in about two seconds, by 
way of example. The central matching host com- 
puter 224 then preferably processes the transaction 
message 120 against she central matching host 
computer 224 stored copy of the system or host 

ss book which is contained in the host book data base 
U8. At this point, the central matching host com- 
puter 224 preferably either adds the entry of the 
transaction or the order from integrated keystasion 
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202 to the host book data base 1 1 8 or matches 
that entry against existing bids and offers contained 
in the host book data base 1 1 8. Once that process- 
ing is completed, the central matching host com- 
puter 224 is ready to generate output messages 
not only to the originating keystation 202. but pos- 
sibly to other keystations, such as the counterparty 
keystations represented by 206 and, assuming that 
an update message is required, to all keystations 
which have logged on to the matching communica- 
tion network 220. Thus, matching host computer 
224 generates directed messages back to each of 
the keystations involved in the matching transac- 
tion, such as the originating keystation 202, andl 
assuming that there is a match, keystation 206 as 
the counterparty keystation, and generates the up- 
date broadcast message to all keystations logged 
on to the matching network 220. It should be noted 
that, as previously mentioned, a single transaction 
message 120 from keystation 202, whether it is a 
hit, or a take, or a bid, by way of example, could 
result in multiple matches. For example, if keysta- 
tion 202 wants to hit the bid for a quantity of 20, it 
is possible that to satisfy that order more than one 
match could be involved such, as for example, four 
or five different matches, particularly, since the 
keystation book at keystation 202 merely displays 
accumulated summaries of the bids or offers. 

If multiple matches occur, then, thereafter, the 
identity of all of the counterparties involved in the 
multiple matches are displayed on the integrated 
screen display 238 of the originating keystation 202 
for settlement purposes. Thus, on any given trans- 
action, there will always be directed messages 
involving the transaction originator and involving 
one or more counterparties or affected parties in 
that trade or transaction. If the market is an auction 
market, then it preferably has a price depth of one 
so that this determines how many prices the cen- 
tral matching host computer 224 can maintain with 
only one price being maintained in an auction 
market. When a new bid goes in which betters the 
existing bid in an auction market, the existing bid is 
actually removed and effectively cancelled in the 
book. Preferably, after all of the directed messages 
are generated to the counterparties, and the asso- 
ciated directed message acknowledgments, such 
as represented by reference numerals 124, 126, 
128 and 130 in Fig. 30, the update broadcast 
message, represented by reference numeral 132 in 
Fig. 30, is sent to all keystations logged on to the 
matching network 220 regardless of whether or not 
they were involved in their particular matching 
transaction. It should be noted that preferably the 
first six steps illustrated in Fig. 30 with respect to 
the central matching computer 221 are all essenr 
tially asynchronous to any outside events. When 
the keystations 202 and 206 receive the update 


broadcast message, it will be processed, against 
the local keystation book database 110, 112 and 
the local copy of the book will be maintained. As 
was previously mentioned, it should be noted that 
5 this local keystation book 110, 112 is not an exact 
carbon copy of the centra! system book 118, but 
rather is only a selected subset of it which com- 
prises an accumulated summary of bids and offers 
within the assigned display depth. Thus, preferably, 
w Fig. 30 illustrates a generic template for the pro- 
cessing of messages throughout the integrated 
trading system 200 in accordance with the method 
of the present invention in order to provide the 
distributed functionality of the system to keysta- 
/5 tions logged on to the matching network 220. 

It should be noted that the concept of originat- 
ing keystation and counterparty keystation moves 
around with each transaction so that for each trans- 
action the originator may be different and may, for 
20 different transactions occurring at the same time, 
be an originating keystation in one instance and a 
counterparty keystation in another instance, in ad- 
dition, there are other instances in which the 
keystation may merely be a bystander and not 
25 involved in the particular transaction at all. Prefer- 
ably the control of the overall distributed matching 
system is maintained by the central matching host 
computer 224 which operates in accordance with a 
set of rules which govern how the transactions are 
30 processed. Preferably, the central matching host 
computer 224 processes transactions against a 
particular trading instrument in time order of entry 
into the system. In this regard it should be noted 
that it is not time entry of orders per se but time 
35 entry of orders related to a particular trading book 
or trading instrument. Thus, there would be time 
order entry assigned to Yen, a different time order 
entry consideration assigned to Deutsch Marks, 
and so forth if the trading instruments were foreign 
40 exchange currencies. 

In Figs 31-34, which correspond to Figs. 4-6 
and 8 of GB-A-2,224,141, the trading ticket output 
is shown. Pressign the TICKET key on the in- 
tegrated keyboard 240 causes the expanded analy- 
45 sis display mode to be entered or stored in the 
data base server 262. As was previously men- 
tioned, in this mode, the expanded analysis for the 
current conversation, assuming the keystation is 
connected to the conversation communication net- 
so work 218, is displayed on the screen 238. The 
expanded analysis preferably shows the full con- 
tents of all the fields that can appear in the analysis 
except that payment instructions may, if necessary, 
be truncated. In the case of forward deals, prefer- 
55 ably the information for both value dates is shown, 
requiring four transactions. While in expanded ana- 
lysis display mode, the expanded analysis on dis- 
play is preferably kept up-to-date with the con- 
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vetsation. Swapping between two conversaiions 
would automatically preferably swap between she 
two expanded analyses so that the one for the 
current conversation was always visible. The ex- 
panded analysis display mode preferably remains 
in effect until a different use of this display aresa on 
the screen 238 is requested. Preferably, if a print- 
out of the conversation analysis is requested, the 
output on the conversation printer 230 is similar to 
that of the displayed window, although the payment 
instructions may be moved to a separate Sine if 
desired. With respect to printing a conversational 
ticket with the lickei printer 228. the format of the 
ticket is preferably simitar to the expanded analysis 
such as the conversational trading ticket illustrated 
in Fig. 17, however the order of the information 
may be changed to present the more critical in- 
formation first. Of course, although the creation and 
storage of a ticket has been described m terms of 
real time conversation analysis, such a system is 
not necessary for the generation of tickets per se 
which merely requires a local data base storage of 
trading tickets no matter how these trading tickets 
are dynamically created, with she data base server 
262 providing such a local data base storage, by 
way of example, in the i integrated terminal control- 
ler 214, 2i6 for both conversational trading tickets 
and match tickets, with the match tickets being 
stored as pseudo conversation, such as illustrated- 
in Fig. 16, by way of example 

For purposes of better understanding the pre- 
ferred ticket output feed 234, 238, the preferred 
ticket output protocol and process will now. be 
described for handling the transfer of trading ticket 
information between the local data base server 262 
and the back office computer. In this regard, with 
reference to U.S Patent No. 4,745,559 incorpo- 
rated by reference herein, the local data base serv- 
er 262 Is analogous to the local data base de- 
scribed in U.S. Patent No. 4,745.659. except, as 
win be described in greater detail hereinafter, with 
respect to the various differences as it relates to 
the presently preferred ticket output protocol and 
process employed >n ihe system 200. Although, the 
preferred ticket output protocol preferably em- 
ployed in the system 200 preferably employs field 
identifiers or FIDs which are analogous to the field 
identifiers referred to in the aforementioned U.S. 
Patent No. 4,745,559, the information contained 
therein is totally different. In place of the record 
identifier codes or RiCs referred to in the afore- 
mentioned U.S. Patent No. 4,745,559, ihe ticket 
output protocol process preferably employs unique 
daa! identifiers which correspond to the ticket num- 
ber on the printed deal ticket as well as to the 
integrated terminal controller 21 4,218 which con- 
tains the local data base server 262 containing thai 
record. Thus, the deal or trading ticket identifier 


includes the terminal controller identifier as well as 
a ticket number, with deals preferably being given 
sequential numbers in order of their confirmation. 
The sequence is preferably in the rang© of i - 

3 999999, by way of example, for each terminal 
controller 214,218. The deal identifier preferably 
starts with the terminal controller identifier and a # 
and is followed by the sequential number, such as, 
for example. AAAA#1 23456 for deal number 

to 123458 on terminal controller A AAA. in addition to 
retrieving the deal per se. the status of the data in 
She terminal controller system can also preferably 
be retrieved using the terminal controller identifier 
AAAA#INFO. by way oi example. 

is Preferably, as will be described in greater de- 

tail hereinafter, the data base server 252 can sup- 
ply two kinds of data to be retrieved about the 
deals oeing conducted by the keystations asso- 
ciated with that terminal controller 214, 2f6; name- 

ao ly information on a deal, and status information on 
what is stored in the data base. As will be de- 
scribed in greater detail hereinafter, i! is the up- 
dates from the status record which are preferably 
looked at to see if there is a change in status 

;>s indicating that a new frade has arrived, which per- 
mits rapid transfer of trading information, such as 
the trading tickets, without the need for continuous 
polling of the various terminal controllers 214.216, 
It should be noted thai: each terminal controller 

jo 214,216 keeps its own unique record oE deals and 
has its own unique set of deal identifiers which are 
independent of the other terminal controllers 214, 
216 associated with the b3ck office computer, as- 
suming more than one terminal controller is asse- 
ss elated therewith, since a portion of the record iden- 
tifier is Ihe unique identification of the terminal 
controller 214. 216 itself. A daia record associated 
with a terminal controller Identifier or TC!D. is pref- 
erably a collection ot data items with each data 

<io item being assigned a unique Field identifier Num- 
ber or FIO. The presently preferred ticket output 
protocol employed In the system 200 in accor- 
dance with the method of the present invention 
preferably uses the FIO number to identify each 

-*5 data item within a message. Preferably, records in 
the system are grouped into classes, such as for a 
deposit deai, or a swap deal or a single deal, such 
as a spot or outright deal, with each class prefer- 
ably reiating to a set of FIDs called a Field List. 

so The Fteld List is analogous to a template except 
that it relates to the format of the transmission of 
the data as opposed to the display per se, with the 
Field List defining which collection of data items 
will be received for that class of record. This Field 

ss List is preferably contained m the record response 
of the data base server 262 to the request of the 
back office computer for trading ticket information. 
Since single deals such as spot or outright 
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deals; swap deals; and deposit deals have certain 
characteristics unique horn each other, unique field 
identifiers must preferably be provided to distin- 
guish these lypes of deals in the preferred ticket 
output protocol. 

Preferably, requests for the status of the deal 
or trading ticket data base contained in the locai 
data bass server 262 of a particular terminal con- 
troller 214. 21 6 will provide information to the back 
orfice computer on the earliest and latest deal 
identifiers stored at the local d3ta base server 262. 
with the date and time of the trading tickets. This 
information would permit the back office computer 
to determine the range of trading tickets available 
for retrieval. 

Preferably, all fields within the messages trans- 
mitted between the local data base server 282 and 
the back office computer contain ASCI! characters 
which makes them suitabie for display on a video 
terminal with iittie or no additional formatting, thus 
making this data feed ideal for quick implementa- 
tion in a data display system, such as. via the 
integrated screen display 238. 

Fig 31 diagrammaticaity illustrates the various 
portions of the trading ticket output system con- 
cerned with the presently preferred trading ticket 
output protocol' of the system 200. Thus, a conven- 
tional serial tine handler provided by the operating 
system is empioyed with, for convenience of ex- 
planation, the input and output being separately 
illustrated as She input handier 800 and the output 
handier 802. The input process 304 preferably ex- 
tracts input bytes from the serial line via the input 
handler 800 and places the: in an input buffer 806. 
The input buffer 806 performs the checks for input 
packets and checksums and can also set Hags io 
ask the ticket ouipui process 808 to generate the 
control characters ACKNOWLEDGE and NO AC- 
KNOWLEDGE at appropriate points in the output 
stream. The Input process 8(34 also preferably de- 
tects these control characters, such as ACKNOWL- 
EDGE and NO ACKNOWLEDGE, at the appropriate 
points .n the input stream, with the occurrence of 
these control characters being tested for by the 
ticket output process 808 when it has sent a mes- 
sage. The ticket output process 808 is preferably 
scheduled regularly and has several independent 
tasks, the main ones of which are preferably taking 
confirmed bytes from she input buffer 806 and 
placing them in a message buffer 8i0, scanning 
the message 810 to find the next complete mes- 
sage if available and, v^hen found, checking the 
message, if the message is faulty, an appropriate 
error response is sent to the output message buffer 
8t2 If, however, the message is vaild, appropriate 
flags are set to request the required action. Prefer- 
ably, no further messages are then handled by the 
ticket output process 80S until the action is com- 


plete. If a ticket or status report is requested by an 
input message, then the ticket output process 808 
preferably gathers the daia from the ticket data 
base 814 and places it in the defined format, 

s determined by the Field List, in the output mes- 
sage buffer 812. When a message has been as- 
sembled in the output message buffer 812, the 
ticket output process 808 preferably adds the ap- 
propriate control bytes and transfers it to the output 

w handler 802. passing as many characters as the ■ 
output handler 802 can accept, at a time. until the 
whole message has been transferred to the back 
office computer from the local data base server 
282. The ticket data-base process 814 is preferably 

15 modified to support updates of the status data in 
the ticket output protocol. The addition is prefer- 
ably required when the data base is modified by 
the addition of a new trading ticket or the removal 
of an ofd ticket. In these cases, the ticket data base 

20 process 816 preferably sefs a flag so that She 
update wili be created by the ticket output process 
808, with the flag being cleared, as appropriate, by 
the ticket output process 808. The ticket data-base 
process 816 is preferably designed so that it adds 

2S a ticket to the end of the data base 814 and 
obtains space as necessary by removing the earli- 
est tickets from the beginning of the data base 814. 
Either of those changes afters the status of !he data 
base 814 so that when there is a status check by 

30 the back orfice computer, the back office computer 
is. thus, advised of the addition of a trading ttcket 
by detecting the change in status. This is indicated 
to the tickei output process S08 by setting out a. 
flag which is .cleared, when appropriate, by the 

35 ticket output process 808. 

Fig. 32 further illustrates the presently pre- 
ferred operation of the ticket output process 808 
which, as can be seen, is entered at frequent 
intervals. The logic preferably gives priority to re- 

40 sponses to requests, and handles one request at a 
time. A request preferably remains in the input 
message and analysis stage 81 0 until it has been 
answered. When any message has been created 
for output, preferably the ticket output process 808 

«5 is dedicated to the output of the message until it 
has been ACKNOWLEDGED or has been transmit- 
ted a given number of times without acknowledg- 
ment. Preferably, when no message is being out- 
put, the ticket output process 808 checks to see if 

so an input message has requested a trading ticket is 
so, the trading ticket is retrieved, a message is 
created according to the type of ticket by use of 
the Field List, and the new message is marked for 
output to the back office computer. When no ticket 

55 is being requested. She ticket output process 808 
preferably checks if the status record has been 
requested. If so. the status data is preferably ob- 
tained and the status record is set up for output in 

2i 
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3 similar way to the trading ticket output. If, how- 
ever, no status is requested, then the ticket output 
process 808 preferably checks !o see if the status 
h3s been marked as changed by the ticket data 
base process 816. if a change is detected, the flag 
indicating the change is preferably cleared, The 
logic then preferably checks it the status record is 
currently requested in an updating mode. If this 
has occurred, lb© new status is preferably output 
on the line and the ticket output process 808 cre- 
ates a new status in the output message buffer 312 
and then arranges that it wiii output the message, 
in the aforementioned implementation, the status 
record is preferably updated by retransmission of 
the whole status record, if none of the above con- 
ditions exist, the ticket output process 808 men 
preferably tries to find a complete new input mes- 
sage. If this succeeds, the ticket output process 
808 preferably analyzes the Input message. A valid 
message causes a change in the analysis data. 
The analysis ol 3 valid message requesting data 
sets flags which then cause the ticket output pro- 
cess BOS to generate the requested output as it is 
rescheduled repeatedly. Other valid messages just 
change the current state of the analysis data, 
whereas invalid messages cause the ticket output 
process 808 to generate an appropriate error re- 
sponse. The above described procedure is illus- 
trated in the flow diagram or Fig. 32. 

Referring now to Fig. 33 the operation of the 
terminal controller data base server 262 when a 
new trading ticket has been generated is shown. 
Thus, when a new deal is generated, as repre- 
sented by reference numeral 850, the trading ticket 
corresponding to the deal is added to the list of 
deals, wrth allocations of the deals or tickets being 
in numerical order as was previously described, 
such as represented by reference numerai 852 
The status record is then updated, giving the last 
deal number, as represented by reference numerai 
854. and a deter ruination is made as to whether the 
deai status is being retrieved with an update, as 
represented by reference numerai 866 If the deal 
status is being retrieved with an update, the update 
is sent to the b3Ck office computer to update the 
status record, such as represented by reference 
numeral 858. and if it is not. then the routine ends, 
as represented by reference numeral 860, 

Referring now to Fig, 34. a flow chart is shown 
of the operation of the local data base server 262. 
wish respect to requests for tickets received by the 
Socal data base server 282 from the back office 
computer. Thus, the trading ticket requested by the 
back office computer is requested by Deat Iden- 
tifier, which, as previously mentioned, does not 
specify the type of deal. This is represented by 
reference numeral 900. The type o! deaf indicated 
is then looked at in the ttcket record being re- 


trieved, as represented by reference numeral 902, 
and the ticket output message is then formatted 
using the Fiefd List specific to the type o! deal, as 
represented by reference numerai 304 in Fig, 34. 

s The formatted record response message, which 
now contains information as to the type of deaf, as 
well as the various parameters and values asso- 
ciated with them, is then sent to the back office 
computer in the appropriate deal format, based on 

io the Field List contained in the retrieved record and. 
for the first time, the back office computer finds out 
what type of deal was involved with the request. 
This is represented by reference numeral 90S- U 
should be noted, 3s previously mentioned, the re- 

f5 quest by the back office computer and the re- 
sponse to the back office computer from the !oca! 
database server 262. contain a "Tag" which iden- 
tifies the particular request being made. 

Thus, by employing the integrated trading 

so method of fhe present invention, the speed and ' 
reliability of both automatic matching and negoti- 
ated video conversational trades may be combined 
in a single system to provide individual subscribers 
with maximum flexibility and optimal efficiency to 

25 effectuate and complete the type of trade demand- 
ed by the time and circumstances available, and to 
generate a ticket corresponding to fhe trade, ir- 
respective of the type of trade transacted. 

in the first aspect of the invention as defined 

30 by Ctaim t, the system may further comprise a 
second interface means eonnectabiy disposed be- 
tween at least one of said keystation means in said 
second plurality of keystation means and said first 
communication means ior selectively interfacing 

ss said one of said keystation means in said second 
plurality of keystation means with said first commu- 
nication means, said one of said keystation means 
in said second pfuraiity of keystation means com- 
prising video display means capabie of displaying 

40 both said bids and said offers. The common data 
mput means may further comprise means ior tog- 
gling between said matching trades and said video 
conversational negotiated trades for selectively ef- 
fectuating said trades via said one of said keysta- 

■rs tion means tn said second plurality of keystation 
means. On of the keystation means m sa<d second 
plurality of keystation means further comprises 
means for selectively varying the content of the 
display on said common video display means in 

so - response to said toggling of said data input means. 

in the first aspect of the invention as set out m 
Ctaim 1 , the keystation means may comprise a 
computer means. Whether it does or not, the inter- 
face means may comprise a conversation server 

35 means for interfacing said video conversational tex- 
tual data messages with said first communication 
means. Whether it does or not, the interface means 
may comprise a concentrator computer means for 
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interfacing said bids and said offers with said first 
communication means. When the keystation means 
does comprise a computer means, the data input 
means may further comprise means for periodically 
providing a keep alive signal to said keystation 
computer means, said keystation computer means 
comprising means responsive to said periodically 
provided keep alive signal for deleting said selec- 
tively provided bids and offers selectively provided 
from said keystation means associated with a given 
data input means when said keep alive signal pe- 
riodically provided from said associated data input 
means is not provided. The means responsive to 
said periodically provided keep alive signal may 
comprise means for automatically terminating con- 
tact with all other keystation means in said system 
for a given keystation means associated with said 
given data input means when said keep alive signal 
periodically provided from said associated given 
data input means is not provided. 

In the first aspect of the invention as set out in 
Claim 1, the interface means may comprise a 
uniquely identifiable local data base for initially 
collecting trading ticket information relating to both 
said automatically matched trades for said trading 
instruments and video conversational negotiated 
trades for said trading instruments, and means for 
communicating said collected trading ticket infor- 
mation to a remote back office data base; whereby 
a common ticket generation scheme may be em- 
ployed in said integrated trading system for said 
trading instruments irrespective of the type of 
trade. The interface means may further comprise 
and integrated terminal controller means connec- 
tably disposed between said keystation means, 
said first communication means, and said uniquely 
identifiable local data base for selectively interfac- 
ing said keystation means with said first commu- 
nication means. Alternatively, the interface means 
may further comprise means for initially collecting 
said trading ticket information corresponding to 
said trades as self-contained integral trading ticket 
records and storing said self-contained integral 
records at said uniquely identifiable local data 
base. The collecting and storing means may further 
comprise means for storing said self-contained in- 
tegral records at said uniquely identifiable local 
data base unique identification and a sequential 
number corresponding to the order of confirmation 
of each of said trades at said local data base. The 
sequential numbers may be independent of the 
type of trade conducted through said integrated 
system. The system may further comprise means 
for retrievably requesting trading tickets from said 
local data base for providing said trading tickets to . 
said remote back office data base independent of 
the type of trade involved. 

In the first aspect of the invention as set out in 
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Claim 1, the system my further comprise a host 
computer means for maintaining a host book data 
base comprising all of the active bids and offers 
associated with said matching transactions in the 

5 system by trading instrument, at least one of said 
first plurality of keystation means comprising a 
transaction originating keystation means for provid- 
ing a bid on a given trading instrument to said 
system for providing a potential matching transac- 

w tion and at least one of said second plurality of 
keystation means comprising a counterparty 
keystation means for providing an offer on said 
given trading instrument involved in said potential 
matching transaction, said first communication 

15 means interconnecting said host computer means, 
said transaction originating keystation means and 
said counterparty keystation means in said inte- 
grated system for enabling data commnication 
therebetween for effectuating said automatically 

20 provided matching transactions. The host computer 
means may comprise means for processing said 
matching transaction for a given trading instrument 
in time order entry to said system. Alternatively, 
both said transaction originating keystation means 

25 and said counterparty keystation means for said 
potential matching transaction may each have an 
associated local data base keystation book com- 
prising a subset of said host book. The keystation 
means associated with said potential matching 

30 transaction may comprise means for displaying 
said associated keystation book on video display 
means. Alternatively, the content of each of said 
keystation books may have an associated display 
depth range controllable by said host computer 

35 means and being updatable by transaction update 
broadcast messages received from said host com- 
puter means through said first communication 
means. The transaction originating keystation 
means and said counterparty keystation means 

40 comprise means responsive to said received trans- 
action update broadcast messages for updating 
said associated keystation books and means for 
providing directed messages to said host computer 
means corresponding to said bid and offer, respec- 

45 tively, said direct messages updating said host 
book. The host computer means may comprise 
means for conditionally providing said transaction 
broadcast update meassages to said keystation 
means associated therewith in response to the 

so presence of an update condition, said update con- 
dition comprising updating of said host book and 
said received bid or offers within said host book 
having a relative value compared with other bids or 
offers within said host book which is within said 

55 keystation book display depth range, of relative 
values; whereby controllable subsets of a dis- 
tributable system trading book may be selectively 
provided to trading keystations in said integrated 
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system from the host for control lably masking the 
available trading market for said automatically 
matched trades. 

!rt ihe first aspect of the invention as sot out in 
Claim 1, trie data input means may further com- 
prise means for periodically providing a keep alive 
signal to said interface means, said interface 
means comprising moans responsive to said pe- 
riodically provided keep alive signal for automati- 
cally terminating contact with afl other keystation 
means in said system for a given keystation means 
associated with said given data input means when 
said keep alive signal periodically provided from 
said associated given data input means is not 
provided. 

In the second aspect of the invention as se! out 
in Claim 8, the common data input means may 
further comprise means for toggling between said 
matching trades and said video conversational ne- 
gotiated trades for selectively effectuating said 
trades via said first keystation means. The first 
keystation means may further comprise means for 
selectively varying the content of the display on 
said common video display means in response to 
said toggling of said data input means. The means 
for selectively varying the display content of said 
common video display means may comprise 
means for varying the format of said display on 
said common video display means in response to 
said toggling of said data input means. 

in the second aspect of the invention as set out 
in Ctaim 8, the system may further comprise a 
second integrated terminal comoriier means con- 
nectabiy disposed between at least a second 
keystation means and said data communication 
network for selectively interfacing said second 
keystation means with said data communication 
network, said second keystation means comprising 
a common video display means capable of display- 
ing both said bids and said offers associated with 
said matching transactions and said video con- 
versational textual data messages associated with 
said negotiated trades, and a common data input 
means for selectively inputting both said video con- 
versational textual data messages to said data 
commoication network through said second inte- 
grated ierminai controller means for effectuating 
said video conversational negotiated trades and 
said bids and said offers to said data commnication 
network through said second integrated terminal 
controller means tor effectuating said automatically 
provided matching transactions. 

in the second aspect of the invention as set out 
in Claim 8, the integrated terminal controller means 
may comprise a concentrator computer means for 
interfacing satd bids and said offers with said data 
communication network. Alternatively, it may com- 
prise a conversation server means for interfacing 


said video conversational textual data messages 
with said data communication network, in this case, 
the conversation server means may further com- 
prise common data base means for integrating 

5 trade data relating to both said bids and said offers 
and said video conversational textual data mes- 
sages. Alternatively, the integrated terminal control- 
ler means may further comprise a concentrator 
computer means for interfacing said bids and said 

'0 offers with said data communication network. The 
integrated terminal controller means may further 
comprise a local area network means for tieing said 
conversation server means, and said concentrator 
computer means together. The first keystation 

/s means may comprise a terminal computer means, 
said terminal computer means being tied to said 
locai area network means. 

in the second aspect ot the invention as set out 
in Claim 3< the first keystation means may com- 

20 prise a computer means. The data input means 
may further comprise means for periodically pro- 
viding a keep alive signal to said first keystation 
computer means, said first keystation computer 
comprising means responsive to said periodically 

25 provided keep alive signal for deleting said selec- 
tively provided bids and offers selectively provided 
from said first keystation means associated with 
said data input means when said keep alive signal 
periodically provided from said data input means is 

so not provided. The means responsive to said pe- 
riodically provided keep alive signal comprises 
means for automatically terminating contact with all 
other keystation means tn said system for said first 
keystation means associated with said given date 

35 input means when said keep alive signal periodi- 
cally provided from said associated data input 
means is not provided. 

In she second aspect of the invention as set out 
in Claim 8, the integrated terminal controller means 

40 may comprise a uniquely identifiable local data 
base for initially collecting trading ticket information 
relating to both said automatically matched trades 
for said trading instruments and video conversa- 
tional negotiated trades for said trading instru- 

4$ ments, 3nd means for communicating said col- 
lected trading ticket information to a remote back 
office data base; whereby a common ticket genera- 
tion scheme may be employed in said integrated 
trading system for said trading instruments ir- 

50 respective of the type of trade. The integrated 
terminal controller means may further comprise 
means for initially collecting said trading ticket in- 
formation cot re spending to said trades as self- 
contained integral trading ticket records and storing 

55 said self-contained integrsf records at said uniquely 
identifiable locai data base Alternatively, the in- 
tegrated terminal controller means may comprise a 
conversation server means for interfacing said vid- 
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eo conversational textual data messages with said 
communication network. The conversation server 
means may comprise means for communicating 
said collected trading ticket information to said 
remote back office data base. 

In the second aspect of the invention as set out 
in Claim 8, at least said first keystation means may 
further comprise pointer means for locating data 
display areas in a windowed textual video display 
on said video display means, and storage means 
for retrievably storing a plurality of unique keysta- 
tion contact signals capable of initiating conversa- 
tion contact with at least one of said other keysta- 
tion means through said data communication net- 
work, each of said other keystation means having a 
unique associated identification code, said keysta- 
tion contact signals corresponding to said unique 
associated identification codes, said windowed tex- 
tual video display comprising a- windowed display 
of at least one of said unique associated iden- 
ficiation codes, said pointer means comprising 
means capable of locating said windowed display 
of said unique associated identification code in said 
windowed textual video display and providing a 
conversational contact message signal to said 
keystation storage means in response thereto for 
retrieving said unique keystation contact signal cor- 
responding to said located unique associated iden- 
tification code for providing a calling signal to said 
corresponding keystation means through said data 
commnication network. The pointer means may 
comprise a mouse. 

In the second aspect of the invention as set out 
in Claim 8, the system may further comprise inter- 
face means comprising said integrated terminal 
controller means and a uniquely identifiable local 
data base for initially collecting trading ticket in- 
formation relating to both said automatically 
matched trades for said trading instruments and 
video conversational negotiated trades for said 
trading instruments, and means for communicating 
said collected trading ticket information to a remote 
back office data base, whereby a common ticket 
generation scheme may be employed in said in- 
tegrated trading system for said trading instru- 
ments irrespective to the type of trade. 

In the second aspect of the invention as set out 
in Claim 8. the system may further comprise a host 
computer means for maintaing a host book data 
base comprising all of the active bids and offers 
associated with said matching transactions in the 
system by trading instrument, at least said first 
keystation means comprising a transaction originat- 
ing keystation means for providing a bid on a given 
trading instrument to said system for providing a 
potential matching transaction and at least on of 
said other keystation means comprising a counter- 
party keystation means for providing an offer on 


said given trading instrument involved in said po- 
tential matching transaction, said data communica- 
tion network interconnecting said host computer 
means, said transaction originating keystation 

s means and said counterparty keystation means in 
said integrated system for enabling data comm- 
nication therebetween for effectuating said auto- 
matically provided matching transaction. Both said 
transaction originating keystation means for said 

w potential matching transaction each have an asso- 
ciated local data base keystation book comprising 
a subset of said host book. Alternatively or in 
addition, both said transaction originating keysta- 
tion means and said counterparty keystation means 

75 for said potential matching transaction each have 
an associated local data base keystation book com- 
prising a subset of said host book. 

In the second aspect of the invention as set out 
in Claim 8, the data input means may further 

20 comprise means for periodically providing a keep 
alive signal to said integrated terminal controller 
means, said integrated terminal controller means 
comprising means responsive to said periodically 
provided keep alive signal for automatically termi- 

25 nating contact with all other keystation means in 
said system for said first keystation means asso- 
ciated with said data input means when said keep 
alive signal periodically provided from said asso- 
ciated data input means is not provided. 

30 In the third aspect of the invention as set out in 

Claim 9, the method may further comprise the step 
of sharing the use of said data input means at said 
given keystation means for inputting said bids and 
said offers associated with said matching transac- 

35 tions and said video conversational textual data 
messages associated with said video conversa- 
tional negotiated trades. Whether it does or not, the 
method may further comprise a step of integrating 
initial access to both said matching trades and said 

40 video conversational negotiated trades in said sep- 
arate networks. Separate networks may be for the 
given keystation means for enabling the given 
keystation means selectively to effect both said 
automatic matching trades and said video con- 
45 versational negotiated trades through said separate 
networks. 

In the third aspect of the invention as set out in 
Claim 9, the method may further comprise a step 
of sharing the use of said data input means for a 

so given keystation means for selectively providing 
transactional data with respect to both said auto- 
matic matching trades and said video conversa- 
tional negotiated trades to said system. In the third 
or fourth aspects of the invention as set out in 

55 Claims 9 and 10 respectively, the method may 
further comprise a step of retrievably storing com- 
pleted trades from both said automatic matching 
trades and said video conversational negotiated 
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trades together. 

Its She fourth aspect of the- invention as set out 
in Claim 10. me method may further comprise a 
step of commoniy collecting trading ticket informa- 
tion relating to both said automatically matched 
trades tor trading instruments traded through said 
first data communication network and said video 
conversational negotiated trades for trading instru- 
ments traded through said second data commu- 
nication network. There may be a further step of 
communication S3id commoniy collected trading 
ticket information to a remote back office data base 
irrespective of the type of trade effectuated' through 
said integrated terminal controller. Said commu- 
nicating step may further comprise the step of 
communicating said collected trading ticket infor- 
mation as self-contained integral trading ticket 
records- 

In the fourth aspect of the invention as set out 
in Claim JO, the method may iruther comprise the 
steps of maintaining a host boots data base com- 
prising the active bids and offers associated with 
said matching transactions by trading instrument, 
and interfacing said given keystation means with 
said host book data base through said integrated 
terminal controller for effectuating said automati- 
cally provided matching transactions. Whether it 
does or not, the method may further comprise the 
step of processing said matching transactions for a 
given trading instrument in time order entry to said 
first data commnication network, when it does corn- 
prise the step of maintaining a host book data 
base, it may further comprise a step of locally 
storing a subset of said host book data base at 
said given keystation means associated with said 
potential matching transactions. It may then com- 
prise a step of providing transaction update broad- 
cast messages to said given keystation means 
through said first data communication network and 
said integrated terminal controller for updating said 
focatly stored subsets in accordance with said 
transactional data relating to said automatic match- 
ing transactions. The transaction update broadcast 
message providing step may further comprise the 
step of selectively providing said update messages 
in response to a predetermined condition. The up- 
date message selective providing step may com- 
prise the step of controifably masking She available 
trading market for said automatically matched 
trades at said given keystation means. 

tn the fourth aspect of the invention as set out 
in Claim 10, the given keystation means may com- 
prise computer means, said method further com- 
prising the step of periodically providing a keep 
alive signal from said given keystation data input 
means to said given keystation computer means, 
and deleting said bids and offers provided Irom 
said given keystation means when said keep alive 


signal is not periodically provided from said given 
kij-ysfation data input means. The method may then 
further comprise a step automatically terminating 
contact with elf other keystation means in said 
s system for said given keystation means when said 
keep alive signal is not periodically provided from 
said given keystation data input means. 

Claims 

1. An integrated trading system capable of provid- 
ing both automatic matching trades for trading in- 
struments between potential counterparties at dif- 
ferent locations and vicieo conversational negoti- 
>s afed trades for trading instruments between poten- 
tial counterparties at different locations over a first 
communication means, said automatic matching 
trades comprising trades in which bids from poten- 
tial counterparties are automatically matched 
so against offers from potential counterparties for giv- 
en trading instruments for automatically providing 
matching transactions in order to complete said 
automatic matching trades for said given instru- 
ments, said video conversational negotiated trades 
25 comprising trades in which video conversational 
textual data messages are selectively routed be- 
tween potential counterparties with respect to bids 
and offers for given trading instruments for en- 
abling discretionary conversational messages to be 
,?o exchanged between said potential counterparties in 
order to negotia'oiy completed said video conversa- 
tions* negotiated trades, said integrated trading 
system comprising a first plurality of keystation 
means; and a second communication means, said 
as first plurality of keystation means being selectively 
connaciabie to said first communication means 
through said second communication means for en- 
abling said first plurality of keystation means to 
selectively communicate with a second plurality of 
40 keystation means at said different locations to ef- 
fectuate said matching trades and said video con- 
versational negotiated trades, at least a first one of 
said keystation means in said first plurality being 
capable of effectuating at least said automatic 
46 matching trades and at least a second one of said 
keystation means In said first plurality being ca- 
pable of effectuating at least said video conversa- 
tional negotiated trades, said first one .of said 
keystation means in said first plurality comprising 
50 video display means capable of displaying at least 
said bids and said offers associated with said 
matching transactions and a data input means for 
selectively inputting said bids and said offers to 
said first communication means through said sec- 
55 ond communication means for effectuating said 
automatically provided matching transactions, said 
second one of said keystation means in said first 
plurality comprising video display means capable 
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of displaying said video conversational textual data 
messages associated with said negotiated trades 
and a data input means for selectively inputting 
said video conversational textual data messages to 
said first communication means through said sec- 
ond communication means for effectuating said 
video conversational negotiated trades, said second 
communication means comprising interface means 
connectably disposed between said first one of 
said keystation means in said first plurality and 
said first communication means and said second 
one of said keystation means in said first plurality 
and said first communication means for selectively 
interfacing said first one of said keystation means 
in said first plurality and said second one of said 
keystation means in said first plurality with said 
keystation means in said second plurality through 
said interface means and said first communication 
means; whereby both automatically matched trades 
for said trading instruments and video conversa- 
tional negotiated trades for said trading instruments 
may be conducted through said integrated trading 
system. 

2. An integrated trading system in accordance with 
claim 1 wherein said first communication means 
comprises separate communication paths for said 
matching trades and said video conversational ne- 
gotiated trades. 

3. An integrated trading system in accordance with 
claim 1 wherein said second communication means 
comprises a common communication path for said 
matching trades and said video conversational ne- 
gotiated trades. 

4. An integrated trading system in accordance with 
claim 3 wherein said second communication means 
common communication path comprises a local 
area network means. 

5. An integrated trading system in accordance with 
claim 1 wherein at least said video display means 
for said first one of said keystation means in said 
first plurality further comprises means capable of 
displaying said video conversational textual data 
messages associated with said negotiated trades 
for effectuating said matching trades. 

6. An integrated trading system in accordance with 
claim 5 wherein said first communication means 
comprises separate communication paths for said 
matching trades and said video conversational ne: 
gotiated trades. 

7. An integrated trading system in accordance with 
claim 5 wherein at least said data input means for 
said first one of said keystation means in said first 
plurality comprises a common data input means for 
selectively inputting both said video conversational 
textual data messages to said first communication 
means through said second communication means 
for effectuating said video conversational negoti- 
ated trades and said bids and said offers to said 


first communication means through said second 
communication means for effectuating said auto- 
matically provided matching transactions. 

8. An integrated trading system capable of selec- 
s tively providing both automatic matching trades for 

trading instruments between potential counterpar- 
ties and video conversational negotiated trades for 
trading instruments between potential counterpar- 
ties over a data communication network, said auto- 

70 matic matching trades comprising trades in which 
bids from potential counterparties are automatically 
matched against offers from potential counterpar- 
ties for given trading instruments for automatically 
providing matching transactions in order to com- 

15 plete said automatic matching trades for said given 
instruments, said video conversational negotiated 
trades comprising trades in which video conversa- 
tional textual data messages are selectively routed 
between potential counterparties with respect to 

20 bids and offers for given trading instruments for 
enabling discretionary conversational messages to 
be exchanged between said potential counterpar- 
ties in order to negotiably complete said video 
conversational negotiated trades, said integrated 

25 trading system comprising at least a first keystation 
means selectively connectable to a plurality of oth- 
er keystation means through said data communica- 
tion network for enabling said first keystation 
means to selectively communicate with said other 

30 keystation means to effectuate said matching 
trades and said video conversational negotiated 
trades; and integrated terminal controller means 
connectably disposed between said . first keystation 
means and said data communication network for 

35 selectively interfacing said first keystation means 
with said data communication network, said first 
keystation means comprising a common video dis- 
play means capable of displaying both said bids 
and said offers associated with said matching 

40 transactions and said video conversational textual 
data messages associated with said negotiated 
trades, and a common data input means for selec- 
tively inputting both said video conversational tex- 
tual data messages to said data communication 

45 network through said integrated terminal controller 
means for effectuating said video conversational 
negotiated trades and said bids and said offers to 
said data communication network through said in- 
tegrated terminal controller means for effectuating 

50 said automatically provided matching transactions; 
whereby both automatically provided matched 
trades for said trading instruments and video con- 
versational negotiated trades for said trading instru- 
ments may be selectively conducted over said 

55 integrated trading system. 

9. An integrated trading system method for provid- 
ing both automatic matching trades for trading in- 
struments between potential counterparties and 
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video conversational negotiated trades for trading 
instruments between potential counterparties over 
separate networks bating to said automatic match- 
ing trades and said video con versa! ionai negotiated 
trades, each of said networks comprising a plurality 5 
of keystation means selectively correctable so 
each other through said separate network, said 
keystation means comprising data input means and 
video display means; said method comprising the 
steps of sharing use of said video dispiay means fo 
for a given keystation means for enabling said 
given keystation means to transact both said auto- 
matic matching trades, in which bids from potential 
counterparties are automatically matched against 
offers from potential counterparties for given trad- ;s 
ing instruments for automatically providing match- 
ing transactions in order to complete said auto- 
matic matching trades for said given trading instru- 
ments, and said video conversationai negotiated 
trades, in which video conversational textual data 20 
messages are selectively routed between potential 
counterparties with respect to bids and offers for 
given trading instruments for exchanging discre- 
tionary conversationai messages between said po- 
tential counterparties for negotiably completing said ss 
video conversationai negotiated trades: and selec- 
tively interfacing said given keystation means with 
both of said separate networks for selectively con- 
necting said given keystation means to keystation 
means in both of said separate networks for en- so 
abling said given keystation means to selectively 
transact both said automatic matching trades and 
said video conversationai negotiated trades through 
said separate networks; whereby both said auto- 
matically provided matching trades and said video 35 
conversational negotiated trades may be conducted 
at said given keystation means for trading desired 
trading instruments irrespective of the type of 
trade. 

10. An integrated trading system method for pro- <w 
viding both automatic matching trades for trading 
instruments between potential counterparties over a 
first data communication network to a plurality of 
keystation means selectively correctable to each 
other through said first data communication net- 43 
work and video conversational negotiated trades for 
trading instruments between potential counterpar- 
ties over a second data communication network to 
a plurality of keystation means selectively connec- 
tabie to each other through said second data com- so 
munication network, said keystation means com- 
prising data inpul means and video display means, 
said keystation means being selectively connec- 
table to both said first and second data commu- 
nication networks through interface means for se- ss 
tectively interfacing said keystation means with 
each other through said first and second data com- 
munication networks, said method comprising the 


step of providing transactional data between said 
keystation means and said potential counterparties 
relating to both said automatic matching transac- 
tions and said video conversational negotiated 
trades through a common integrated terminal con- 
troller means for enabling a given keystation means 
to selectively eflectuate both said automatic match- 
ing transactions and sa<d video conversational ne- 
gotiated trades through said common integrated 
terminal conlrofiar to said' first and second data 
communication networks, respectively. 
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APPENDIX 
TABLE A 


• inctuoe <uno«f.n> 
•undef NOMEMMGR 
•undaf NOWINMESSAGES 


ROTS 
) APPLICATION; 


s_ouesysent. 

s'logoffsent. 
s^logoffwait, 


SJJARUOGGINGON, 
S~ROTSLOGG InGOn , 
S_ACTIVE. 
SJJARTACTIVE. 
s'lNhlBITEO. 

) R0f_ST*TES; 


'OISOuERVlOGOFF ana am waiting for 
i RCIS OLRESONSE ana waiting for ot 
a «OIS_LOG0FF to ootn parties •/ 



static vo'O tOCAL Se-.RO:S:a;e .-;:_:'--£S 5); 

itatic «0>d LOCAL TeUROTSLOaco :.z-g .»jran|; 

itatic WORO LOCAL GetNe- la («p=l:C;'::n «pd) . 

static .om local SenoLogcff (lo-? s-«on),' 
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f Sj.0G£5£iX>f P- 
» S_tOGO*f'StMT- 
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»-»« 5_«C 

svitcn t ) * ° 

( 

/* SC3T5 'tswrts l><-* e;»« •H.t c*.«r can car-y on */ 
tit '*«tf("80TS U*e rcrt'.A-); 

Set«5rSt4t* (S_*tr:vfj. 

cim5*«9n„„ 9 « («oo_^:, f , tois_* ui .osoea»i. o, as.}- 


CtrtSe^N**„ 3B {MOOOAf»T, SCtS i.C«3ff. 0*'tt«( <«»«> tf WSESI. 
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ise L0_*lflEA0vON: 

SetROIStat* (S_l.OGGE0OFF) 


: void LOCAL ROISLcggeeOf f (hwno bwnd . WORD -Id) 
Indies the RDIS_lCGGEO_OFF messages 


1 LOCAL ROISLoggedOff (mwnO h 


case S_LOGOFFSENT: 

if Twld 0«rtld || 

SetflOIState ( S_LCGOf--- . ' 


e S_LOGOFFWAIT: 
SetROIState <S_LOGGE0OFF) 
3eBugging s^o 


, OM_STARTOIALOG. hwna, MAKELCNG (SO LOGON, 0)); 

. OM_STARTOIALOG. hWnd. MAKELCNG ( SD_CHANGE_OEALER. 
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/• save reason for logoff message •/ 
Logoff Reason = Reason: 

SetROIState (S_CUERYS£NT) ; 

/• post messages to DART aro ROTS reguesting that they log off 
Oartld = GetNe-Id (OaRT); 

CtrlPostMessage (K)0_C*RT. ROIS OueRYLOGOFF . Oartld. OU ; 

Rdtsld = GetNe-Id ^RCTS):' P °* t 9<!Cl tn '' 0,J9^, * / 
while (PostHessage (n—cROfS. ROIS^OUERYLOGOFF, Rdtsld, OL) == 
printf (WHERE "ROI Sosti-essage f a tled\n-); 


» Routine,: void LOCAL HOlSOl r esonse (hwnO hwnd, WORD -Id. WORD nResul 
« handles ROISJXRESPCnSE message 


void LOCAL ROISQlresonse (hwnO -nc . -0R0 -la. WORD nResul t) 

•If defined (DEBUG) 

printf (-ROIS_OLRESPCNS£ - 


case S QUERYSENT : 
{ 

/• check result of i;gs" 


"eak" VlMeSSa9e CMC0 - S;? '- P - SM -" T "N_01ALOG_ABO«TEO. 0. OL): 
ise 0L_»CTIVE: 
SetROlState 9 (S_ACT IvSK 5aCk S -* CTIVE ' / 

't Id 1 ■ - : 3 = = "JCtsId) 

[ALOG. h.Wnd ,MA<ElONG (SO ACTIVE CONVS. 


• wait for the otner sa'ty to '»oi y ./ 
ase S OUERYWA I T : 

s-itcn (nResult) 

{ 

case QL_STOP: 

SetROIState (S_ACTIVE), 

CtrlSenOMessage (nO0_S£-i.P. £ « r ^"oui^G^AaORTEO . 0. OL); 

case OL_ACTIV£: 

/• abort logoff and set RO! s;ate bacx S ACTIVE •/ 

SetROIState (SACUvE); 

If (wld == Oartla || »i<j z= Potsld) 

CtrlPostMessage (MO0_SETuP. 0m_STaRTOIalOG. hWnd .makELONG <s6_ACTIVE_CONVS. 
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ca»» OLOK: 
{ 

equaat from ROTS t 
1 wHl leava zr 


. MAKELONS (SO_AREYOUSURE. 0)); 


SetROIState ( S_LOGOFrs£s: ) : 
Sendlogoff (Logof fReasor; . 


void LOCAL RDISStatus (*0R0 'ea 


•endlf 
switch (st 


case S_0ARTACTIVE: 
casa S~OU£RYSENT : 
case S_QUERYW»tT: 
case S~L0G0FFSENT : 


:ase SjkCTIVE: 

:»»• S_OARTLOGCINGOM: 

:»»• S_R0TSLOGGINGON: 


casa RS_ImperaT[vE: 

SetROIState (S LOGOFFSEst > 
SewJLogoff ((long) LF I*f=E 
break; 


casa RS_HOSTSHUTCCWN: 
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S»t«OtSt*t« (5_0ABT*CTlve>; 
ft(*C*i(l * a«SH«^i<3 (SDfS) . 


R£SC»id * GetK«Ht<J (BgTS); 


C**« »$_».■ I K£O0Wt: 

8tSts!0 = fi*tK«witj (ftOTSt: 

/• * «*U see the »tat* b»« if itn* >* cowuing uo tfwn 
* U»rt ofity is r u r>n>«g ...x* «« should *u«*jy be in tot* *t*t* 

5««*»0tSt»t» (3 OMtTACT.IVSi; 





CtM$«rvw<sss»s» {WOO 0*f*T , =0XS \QGOFF. 
festsia = 6irt«*»I<j (SOTS}. 
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*f*yctJB* i Gia&*tAtt<sc <G*«0 j .-.WE.W SK*se, ilorji ttCSa» OAT*}}- 

H f v ,?*H.£0_E*ir(N*Yeofjy. FTi. J*0_lG«K<_><0<} ; 
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